Missing symbol error when building X.org from git

[Dan Nicholson]

On Fri, Mar 19, 2010 at 8:17 AM, Joel Feiner <jafeiner at gmail.com> wrote:
> On Fri, Mar 19, 2010 at 10:05 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>>
>> On Thu, Mar 18, 2010 at 9:12 PM, Joel Feiner <jafeiner at gmail.com> wrote:
>> > On Thu, Mar 18, 2010 at 4:58 PM, Dan Nicholson <dbn.lists at gmail.com>
>> > wrote:
>> >>
>> >> 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.
>> >
>> > They are now attached.  I stripped out some obvious irrelevant lines
>> > (like
>> > /usr/lib64/dbus*).  It's down to 254 lines, which hopefully shouldn't be
>> > too
>> > much to handle.
>> > I was not where I could go back to my Linux installation when I sent the
>> > 2nd
>> > email.
>> >>
>> >> > 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.
>> >
>> > I'll try a new build in a few minutes and see if deleting the entries in
>> > *.la files in the source tree as well as the build tree makes any
>> > difference.
>>
>> One thing I see that could be causing problems is references to
>> /usr/lib64/libXdmcp.la. Do you have the log from when you built
>> libX11? OK, I think I figured it out. In xorg.modules, can you add a
>> <dep package="libXdmcp"/> under the libxcb module? I think that's
>> where your host's libXdmcp is being picked up and then polluting the
>> whole process afterwards. Most people probably wouldn't see that
>> because the distros remove the .la files in the system lib
>> directories.
>>
> I changed xorg.modules but to no avail.  The log for building libX11 is
> attached (just the output from make and configure). For completeness, I
> attached config.log from libX11 and from xserver, in case those would be of
> any use.

Sorry, due to the viral nature of libtool archives, you'd have to
rebuild libxcb, then libX11, then all the things that depend on it. In
other words, it's probably easier to start a fresh build. But, just to
see if this would fix things, rebuild libxcb and libX11 and see if
there are any references to X libraries in /usr/lib64 in libxcb.la and
libX11.la. The desired effect is that /usr/lib64/libXdmcp.la changes
to $xorg_libdir/libXdmcp.la.

--
Dan