Ian, haven't you seen a problem like this before? I don't remember if we fixed
it or even tracked it down, but it sounds familiar.

I suspect it's a libtool bug, if it's a bug at all, because that ${wl} string
only appears in libtool. I think it's expected to expand to "-Wl,".

Versions look good to me.

Try exporting LIBTOOLIZE=glibtoolize before running ./autogen.sh.

Check your paths to make sure your upgraded tools are running, not the preinstalled out-of-date tools. 
(For reference, I'm using DarwinPorts for my autotools.)

Did you install the xorg macros?

(In reply to comment #2)
> Versions look good to me.
> 
> Try exporting LIBTOOLIZE=glibtoolize before running ./autogen.sh.

I am using libtoolize from libtool 1.5.23a à la:

	env LIBTOOLIZE=/usr/local/bin/libtoolize ... util/modular/build.sh -m /Users/pete/Quellen/
X11R7.1/Mesa-6.5.2 -D /usr/X11R7

This version of libtool did not create a glibtoolize script. /sw/bin/glibtoolize is version 1.5.22. I let 
mostly build.sh do the job from the prepared environment. Only XDarwin and other Apple particles are 
problems that need special treatment ...

> 
> Check your paths to make sure your upgraded tools are running, not the preinstalled out-of-date 
tools. 
> (For reference, I'm using DarwinPorts for my autotools.)

I set also PATH for build.sh:

	PATH=/Users/pete/Quellen/X11R7.1/util/modular:/usr/local/bin:/sw/lib/freetype219/bin:/sw/
lib/odcctools/bin:/sw/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/teTeX/bin/
powerpc-apple-darwin-current

> 
> Did you install the xorg macros?

I don't know what you mean by this. I have in ~/Quellen/X11R7.1 a directory util and inside it a directory 
macros. From time to time I update its contents with git – is there more I should know and apply?

Paths look good.

> > Did you install the xorg macros?
> 
> I don't know what you mean by this. I have in ~/Quellen/X11R7.1 a directory util
> and inside it a directory macros. From time to time I update its contents with git
> – is there more I should know and apply?

You also need to 'sudo make install' the macros whenever they change. They affect the behavior of the 
autotools. Also ACLOCAL needs to be set. XCB prerequisites like this are discussed on the wiki:

  http://xcb.freedesktop.org/wiki/DevelopersGuide
  http://xorg.freedesktop.org/wiki/ModularDevelopersGuide

(In reply to comment #4)
> Paths look good.
> 
> > > Did you install the xorg macros?
> > 
> > I don't know what you mean by this. I have in ~/Quellen/X11R7.1 a directory util
> > and inside it a directory macros. From time to time I update its contents with git
> > – is there more I should know and apply?
> 
> You also need to 'sudo make install' the macros whenever they change.

This happened last when I updated them.

> They affect the behavior of the autotools. Also ACLOCAL needs to be set.

Other environment variables I set are:

ACLOCAL_LOCALDIR=/usr/X11R7/share/aclocal
ACLOCAL="aclocal -I /usr/X11R7/share/aclocal -I /usr/local/share/aclocal -I /sw/share/aclocal" 
PKG_CONFIG_PATH=/usr/X11R7/lib/pkgconfig:/sw/lib/freetype219/lib/pkgconfig:/sw/lib/fontconfig2/
lib/pkgconfig:/sw/lib/pkgconfig:/sw/lib/system-openssl/lib/pkgconfig:/sw/share/pkgconfig:/usr/
local/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/clamXav/lib/pkgconfig

although build.sh sets some of them, but it's easier to copy these ready-made settings to do something 
in the *shell* buffer. Besides these I also have CFLAGS, CPPFLAGS, LDFLAGS, and for example

MACOSX_DEPLOYMENT_TARGET=10.4

Some are set in ~/.MacOSX/environment.plist.

I'll see whether I can read (again) on the wikis (I had to do it before I could start to compile). Right now 
components for XDarwin are bugging me a lot!

And these unresolved macros only exist for XCB components! I could attach 2.5 MB ...

Having updated X11R7.1 also XCB components needed a re-compile. Now I saw this:

	/usr/bin/libtool: internal link edit command failed
	make[2]: *** [libxcb.la] Error 1
	make[1]: *** [all] Error 2

So it's obvious something in libxcb (0.9.93) that resets my PATH from the proper 'env PATH=/Users/
pete/Quellen/X11R7.1/util/modular:/usr/local/bin:/sw/lib/freetype219/bin:/sw/lib/odcctools/bin:/sw/
bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/teTeX/bin/powerpc-apple-darwin-current' 
setting. The faulty line that produced error with "/usr/bin/libtool" is:

gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb.1.0.0.dylib  .libs/xcb_conn.o .libs/
xcb_out.o .libs/xcb_in.o .libs/xcb_ext.o .libs/xcb_xid.o .libs/xcb_list.o .libs/xcb_util.o .libs/
xcb_auth.o .libs/xproto.o .libs/bigreq.o .libs/xc_misc.o  -L/usr/X11R7/lib -L/sw/lib/freetype219/lib -
L/sw/lib/fontconfig2/lib -L/sw/lib/ncurses -L/usr/local/lib -L/sw/lib /usr/X11R7/lib/libXau.dylib /usr/
X11R7/lib/libXdmcp.dylib  -mcpu=7450 -mtune=7450 -multiply_defined -install_name  /usr/X11R7/
lib/libxcb.1.dylib -Wl,-compatibility_version -Wl,2 -Wl,-current_version -Wl,2.0
ld: -multiply_defined: unknown argument: -Zinstall_name

And this is also incorrect: according to PATH ld should be /sw/lib/odcctools/bin/ld ... (and there is only  
"-multiply_defined" without the "suppress" component the LDFLAGS setting!) Is there some pkg-config 
invocation for a non-X11R7.1 thing that might tell a different libtool path name?

Related to bug #8052 perhaps?

(BTW, though I develop XCB on the Mac, I test it against Apple's X server, not X.org, so there are lots of 
differences between my set of packages and yours.)

Ignore that last bug reference... I meant bug #8504.

(In reply to comment #8)
> Ignore that last bug reference... I meant bug #8504.

Yes, there seems to be some connection. For some days I could not see the unresolved macros, then 
they returned.

I had other error messages with XCB because I had not installed Graphviz. When I went to install it, I 
started with swig – and made test or check. During this hour long process I saw error messages from 
Apple's /usr/bin/libtool, so I checked wherever I set PATH (or path for tcsh), and I think I've found an 
error that overrides the setting from ~/.MacOSX/environment.plist! One of the next days it should be 
fixed from my side, I think! (Although it's strange that it only happens with XCB.)

It might get longer to debug this issue:

	checking for XCBPROTO... yes
	checking for NEEDED... configure: error: Package requirements (xau pthread-stubs) were not met:
	
	No package 'pthread-stubs' found

I should not play with 'git pull,' I think ...

Not a problem: you just need to fetch and install a new pthread-stubs package required for some *other* 
variants of FreeBSD. (Although it would be nice to have the libxcb build do the right thing if it isn't 
installed.) I'll update the wiki to note the new dependency.

git-clone git://anongit.freedesktop.org/git/xcb/pthread-stubs

(In reply to comment #11)
> Not a problem: you just need to fetch and install a new pthread-stubs package required for some 
*other* 
> variants of FreeBSD. (Although it would be nice to have the libxcb build do the right thing if it isn't 
> installed.) I'll update the wiki to note the new dependency.

There is also util/modular/build.sh – and maybe also the shell script http://xorg.freedesktop.org/wiki/
ModularDevelopersGuide?action=AttachFile&do=get&target=git_xorg on http://xorg.freedesktop.org/
wiki/ModularDevelopersGuide ...

I corrected some *sh RC files to have the same PATH or path in interactive, non-interactive, and login 
shells. I set the PATH that /sw/lib/odcctools/bin/libtool (does not report a version information) is found 
first. LIBTOOLIZE was set to /usr/bin/glibtoolize. The macro was srill unresolved:

           gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb.1.0.0 ...

A new error was introduced:

	(cd .libs && rm -f libxcb.1 && ln -s libxcb.1.0.0 libxcb.1)
	(cd .libs && rm -f libxcb && ln -s libxcb.1.0.0 libxcb)
	ar cru .libs/libxcb.a  xcb_conn.o xcb_out.o xcb_in.o xcb_ext.o xcb_xid.o xcb_list.o xcb_util.o 
xcb_auth.o xproto.o bigreq.o xc_misc.o~ranlib .libs/libxcb.a
	ar: xc_misc.o~ranlib: No such file or directory
	make[2]: *** [libxcb.la] Error 1

Grep'ping for ~ shows a lot of $this~$that in configure!

My approach was to run 'autoreconf -fvi' and then ./configure ...

I think I'll continue with xcb/util. xcb/proto is at version 1.0.

When in the search path /sw/lib/odcctools/bin/libtool was first, LIBTOOLIZE=/usr/bin/glibtoolize 
produced unusable configure files; when LIBTOOLIZE was /sw/bin/glibtoolize the macros were 
unresolved.

When in the search path /usr/local/bin/libtool was first, LIBTOOLIZE=/usr/bin/glibtoolize produced 
unusable configure files again; when LIBTOOLIZE was /sw/bin/glibtoolize the macros were unresolved; 
and they did not change when I set LIBTOOLIZE to /usr/local/bin/libtoolize.

(In reply to comment #13)

>            gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o 

This is a bug in libtool, and is actually harmless, the ${wl} are shown, but
when the command is executed -Wl, is used. Report the bug (again) at
bug-libtool@gnu.org if you see fit, but I do not have the time to fix such a
cosmetic bug right now :/

Thanks for the info.