Bug 8504

Summary: Unresolved macros when building xcb libs
Product: XCB Reporter: Peter Dyballa <Peter_Dyballa>
Component: LibraryAssignee: Ian Osgood <iano>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: high    
Version: 0.9   
Hardware: PowerPC   
OS: Mac OS X (All)   
Whiteboard:
i915 platform: i915 features:

Description Peter Dyballa 2006-10-04 04:08:33 UTC
When making the manifold of xcb libraries some macros for ld are not resolved on Mac OS X 10.4.7 and 
10.4.8:

gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xlib.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-composite.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-damage.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-dpms.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-glx.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-randr.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-record.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-render.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-res.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-screensaver.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-shape.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-shm.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-sync.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xevie.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xf86dri.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xfixes.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xprint.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xtest.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xv.0.0.0.dylib ...
gcc -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o .libs/libxcb-xvmc.0.0.0.dylib ...

Could be that's the reason the libraries cannot be prebound.
Comment 1 Jamey Sharp 2006-10-04 10:09:00 UTC
I have no idea what's wrong there. Ian Osgood has been building and testing XCB
on MacOS X, so I'm hoping he has some insight.

It seems clear to me that ${wl} should have been replaced with "-Wl," but that's
nothing in our build scripts, I think -- it looks like a libtool bug to me.
Unless it's not a bug at all: are you sure ${wl} isn't set in the shell where
these commands are executing?

Anyway, thanks for the report, and I hope Ian can help.
Comment 2 Peter Dyballa 2006-10-04 14:29:44 UTC
I am compiling in GNU Emacsen (23.0.0 X client, 23.0.0 Emacs.app [OPENSTEP/Cocoa], and 22.0.50). 
There is no such environment variable.
Earlier, in summer, I found a similiar bug in Freetype (http://savannah.nongnu.org/bugs/?17029). Could 
be it is a bug in libtool. I am using a libtool binary from Fink, "Darwin cctools build system/code base to 
support gcc4", probably libtool 1.5.22. Anyway, I have a lot of time to experiment, since compiling Xorg 
7.1 does not work fine and some answers to my bug reports seem to take a detour over a new planet, 
Ceres.

The libtool script has defined on lines
#131:  wl="-Wl,"
#254: allow_undefined_flag="\${wl}-undefined \${wl}dynamic_lookup"
#1748-1754: 	xlinker)
	  linker_flags="$linker_flags $qarg"
	  compiler_flags="$compiler_flags $wl$qarg"
	  prev=
	  compile_command="$compile_command $wl$qarg"
	  finalize_command="$finalize_command $wl$qarg"
	  continue
#2099: 	  arg="$arg $wl$flag"
and some more. If you want I can send a "log" from /bin/sh -x ../libtool --tag=CC --mode=link.

Could be it's all caused by the fact that /bin/sh is /bin/bash in Mac OS X 10.3 and 10.4.
Comment 3 Ian Osgood 2006-10-05 08:19:41 UTC
Several comments and questions:

I haven't yet updated to 10.4.8 (just got the notification).

I am using the glibtoolize installed with XCode 2.2:
$ glibtoolize --version
libtoolize (GNU libtool) 1.5.20
$ LIBTOOLIZE=glibtoolize ./autogen.sh

I am using Darwinports instead of Fink, overriding these packages:
$ port installed
  autoconf @2.59_0 (active)
  automake @1.9.6_0 (active)
  pkgconfig @0.20_0 (active)

I also have some environment variables exported to aid the modular build:
ACLOCAL='aclocal -I /usr/local/share/aclocal'
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/local/lib/pkgconfig

(/opt/local is where Darwinports installs stuff, instead of /sw/local for Fink. The /opt paths are first in 
my PATH. I have the Xorg stuff installing to the default /usr/local.)

Let me know if any of this is useful.

What versions of these tools have you installed?

Are you using the XCode IDE or the command line?
Comment 4 Ian Osgood 2006-10-05 08:29:14 UTC
> I am using the glibtoolize installed with XCode 2.2:

I take that back. I'm using the Darwinports version.
$port search
  libtool @1.5.20_0 (active)

But I do still have to set LIBTOOLIZE=glibtoolize to configure.
Comment 5 Peter Dyballa 2006-10-05 15:32:49 UTC
Setting LIBTOOLIZE produces failures for me – I still build xcb as part of X11R7.1 with build.sh (a bit 
prepared for this single target). I am not sure whether I can achieve the same, or a better result, in a 
different way.

I have the choice between Apple's tools:

	/usr/bin/autoconf --version     => autoconf (GNU Autoconf) 2.59
	/usr/bin/automake --version     => automake (GNU automake) 1.6.3
	/usr/bin/aclocal --version      => aclocal (GNU automake) 1.6.3
	/usr/bin/glibtoolize --version  => libtoolize (GNU libtool) 1.5

and those from Fink:

	/sw/bin/libtoolize --version    => libtoolize (GNU libtool) 1.5.22
	/sw/bin/automake --version      => automake (GNU automake) 1.9.6
	/sw/bin/aclocal --version       => aclocal (GNU automake) 1.9.6
	/sw/bin/autoconf --version      => autoconf (GNU Autoconf) 2.60

pkg-config is still unique (although I compiled pkg-config-0.20 without installing it):

	/sw/bin/pkg-config --version    => 0.21

Since I compile in GNU Emacs I can set in *shell* buffer for configure or other tools a particular 
environment – and the same can be done for compilation. PATH then dictates which utilities were found 
and used.


Experimenting with a few PATH settings it seems that I was using a mixture of Fink and Apple. Since 
Apple provides (g)libtool but no libtoolize (only glibtoolize), obviously Fink's libtoolize was used with the 
Apple tools. This leads to the same error reproducible. Using only Apple's tools the compilation does not 
start:

	Building xcb module component xcb...
	autoreconf: Entering directory `.'
	autoreconf: configure.ac: not using Gettext
	autoreconf: running: aclocal -I /usr/X11R7/share/aclocal  --output=aclocal.m4t
	aclocal: configure.ac: 14: macro `AM_PATH_CHECK' not found in library
	autoreconf: aclocal failed with exit status: 1

But, using Fink's tools *no* macro is left unresolved! So the whole bug was only my fault. Sorry for this!

So the only thing left is a (minor) prebinding problem:

	ld: warning prebinding disabled because (__TEXT segment (address = 0x0 size = 0x18000) 
of .libs/libxcb.0.0.0.dylib overlaps with __TEXT segment (address = 0x0 size = 0x2000) of /usr/X11R7/
lib/libXau.6.dylib


Thanks for making me check things accurately!


To avoid this unresolved macro either DarwinPorts or Fink paths should come before /usr/bin.
Comment 6 Ian Osgood 2006-10-07 22:51:14 UTC
Yes, you have to install new autotools and keep them first in your PATH ahead of Apple's older tools.  XCB 
(and Xorg in general) requires automake 1.7 or better. There is more detail on XCB's developer's guide 
pages:

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

I hope this resolves your issues.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.