Re: lock-keys-applet build failure on x86_64

[Michael Schwendt <bugs michael gmx net>]

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.