Missing symbol error when building X.org from git

[Dan Nicholson]

On Thu, Mar 18, 2010 at 12:41 PM, Joel Feiner <jafeiner at gmail.com> wrote:
> On Thu, Mar 18, 2010 at 3:32 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>>
>> On Thu, Mar 18, 2010 at 10:54 AM, Joel Feiner <jafeiner at gmail.com> wrote:
>> > The error that comes up is this:
>> > libtool: link: gcc -DHAVE_DMX_CONFIG_H -DHAVE_DIX_CONFIG_H -Wall
>> > -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
>> > -Wmissing-declarations -Wnested-externs -fno-strict-aliasing
>> > -Wbad-function-cast -Wformat=2 -Wold-style-definition
>> > -Wdeclaration-after-statement -D_BSD_SOURCE -DHAS_FCHOWN
>> > -DHAS_STICKY_DIR_BIT -I/home/XXXX/xbuild/out/include/pixman-1
>> > -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext
>> > -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi
>> > -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr
>> > -I../../fb -fvisibility=hidden -I../../hw/xfree86/dixmods/extmod
>> > -I/home/XXXX/xbuild/out/include/libdrm -I/usr/include/freetype2 -O2
>> > -mtune=native -march=native -pipe -fomit-frame-pointer -rdynamic -o Xdmx
>> > dmx.o dmxcb.o dmxcmap.o dmxcursor.o dmxdpms.o dmxextension.o dmxfont.o
>> > dmxgc.o dmxgcops.o dmxinit.o dmxinput.o dmxlog.o dmxpict.o dmxpixmap.o
>> > dmxprop.o dmxscrinit.o dmxshadow.o dmxstat.o dmxsync.o dmxvisual.o
>> > dmxwindow.o miinitext.o fbcmap_mi.o panoramiX.o dmx_glxvisuals.o
>> >  -L/home/XXXX/xbuild/out/lib64 ../../fb/.libs/libfb.a
>> > ../../mi/.libs/libmi.a
>> > ../../render/.libs/librender.a ../../Xi/.libs/libXi.a
>> > ../../xkb/.libs/libxkb.a ../../xkb/.libs/libxkbstubs.a
>> > ../../miext/shadow/.libs/libshadow.a
>> > ../../miext/damage/.libs/libdamage.a
>> > ../../Xext/.libs/libXext.a ../../dix/.libs/libmain.a
>> > ../../dix/.libs/libdix.a ../../config/.libs/libconfig.a
>> > /usr/lib64/libhal.so
>> > /usr/lib64/libdbus-1.so ../../os/.libs/libos.a /usr/lib64/libgcrypt.so
>> > -L/usr/lib64 /usr/lib64/libgpg-error.so ../../xfixes/.libs/libxfixes.a
>> > glxProxy/libglxproxy.a input/libdmxinput.a config/libdmxconfig.a
>> > /home/XXXX/xbuild/out/lib64/libXmuu.so /usr/lib64/libXrender.so
>> > /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
>> > /home/XXXX/xbuild/out/lib64/libXfixes.so
>> > /home/XXXX/xbuild/out/lib64/libXi.so
>> > /home/XXXX/xbuild/out/lib64/libXext.so
>> > /home/XXXX/xbuild/out/lib64/libX11.so
>> > /home/XXXX/xbuild/out/lib64/libxcb.so
>> > /usr/lib64/libXdmcp.so -ldl /home/XXXX/xbuild/out/lib64/libXfont.so
>> > /usr/lib64/libfreetype.so /home/XXXX/xbuild/out/lib64/libfontenc.so -lz
>> > /home/XXXX/xbuild/out/lib64/libXau.so
>> > /home/XXXX/xbuild/out/lib64/libpixman-1.so
>> > /home/XXXX/xbuild/out/lib64/libXdmcp.so -lm -lrt -Wl,-rpath
>> > -Wl,/home/XXXX/xbuild/out/lib64 -Wl,-rpath
>> > -Wl,/home/XXXX/xbuild/out/lib64
>> >
>> > /home/XXXX/xbuild/out/lib64/libXi.so: undefined reference to
>> > `XESetWireToEventCookie'
>> >
>> > /home/XXXX/xbuild/out/lib64/libXi.so: undefined reference to
>> > `XESetCopyEventCookie'
>> > What appears to be happening, I think, is that it is getting libraries
>> > like
>> > libXrender and so on from /usr/lib64 instead of my build directory.  I'm
>> > not
>> > sure why libtool is doing this.  I have my PKG_CONFIG_PATH set to my
>> > local
>> > build package config path (/home/XXXX/xbuild/out/lib64/pkgconfig) and
>> > LD_LIBRARY_PATH is also set to that (modulo the pkgconfig part).  I had
>> > also
>> > built the whole get up without using LD_LIBRARY_PATH.  Same results.
>> >  The
>> > only two modules that have this problem are pixman and xserver.  Pixman
>> > I
>> > worked around by passing --disable-gtk to ./configure, since that was
>> > the
>> > part of the build that was failing.  For xserver, it appears to be dmx
>> > that's failing.
>>
>> If I had to guess, the /usr/lib64 is getting hardcoded into one of the
>> .la libtool archives installed in /home. Can you do "grep /usr/lib64
>> /home/XXXX/xbuild/out/lib64/*.la"? Maybe there's a problem with module
>> ordering in xorg.modules. Not sure if that's what's causing the
>> reference errors, though.
>>
>> --
>> Dan
>
> I actually did grep for /usr/lib64 in my ~/xbuild (where the source and
> output trees live) and removed all references in the libtool archives (and
> even in libtool itself!).  It didn't make a difference.

Next time can you record what those references were? That would help
solve this problem.

> Somehow libtool
> found those libraries again.  Note that it *has* found some of the libraries
> in the right place and that's the most confusing part.  I'm not on Linux
> right now, so I can't try diddling with xorg.modules, but I'll try that
> again later this evening or tomorrow.

Well, you would need to clean up in the xserver tree too since now all
the .la files in the tree contain the references to the unwanted
libraries.

> Does X.org require a specific version of libtool?  Perhaps the one I have is
> incorrect or has some bug that interacts badly with X.org builds?  Again, I
> can't check the version right now.

I don't think it's libtool that's causing the problem. It's doing what
it's always done (for better or worse). I suspect the problem is that
there is a module being built out of order that's picking up your
host's libraries because the new ones don't exist yet.

Needs more info, though.

--
Dan