lock-keys-applet build failure on x86_64

Michael Schwendt bugs.michael at gmx.net
Fri Apr 8 16:04:03 UTC 2005


On Fri, 08 Apr 2005 11:27:44 -0400, Ignacio Vazquez-Abrams wrote:

> Okay, here's the error I'm getting:
> 
> gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona
> -o lock-keys-applet lock-keys-applet.o -Wl,--export-dynamic -pthread
> -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2
> -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 /usr/lib/libpopt.so
> -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
> -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
> -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm
> -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0
> /usr/lib/libpopt.so: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> 
> I've seen this error in the IRC channels before, and my response has
> been to remove popt.i386. Obviously this won't work in a mach
> environment, so I was wondering if someone could please take a look at
> lock-keys-applet and figure out what changes would be required to have
> it build properly.
> 
> Or if I could get access to a x86_64 machine myself for testing purposes
> that would be great as well.
> 
> Thanks,

Take a look at the previous line in the build log:

/bin/sh ../libtool --mode=link gcc  -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona   -o lock-keys-applet  lock-keys-applet.o -Wl,--export-dynamic -pthread -L/usr/X11R6/lib64 -lpanel-applet-2 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0     

You can see that ../libtool is called with good linker arguments for
libpopt as taken from the libgnome-2.0 pkgconfig file.  But this libtool
doesn't care about /usr/lib64 and chooses to take libpopt.so from /usr/lib
instead when running gcc, which is what you see in the line you
quoted. So, if you update the included libtool files (libtoolize...),
that should fix it.




More information about the fedora-extras-list mailing list