[Clfs-support] strange libtool

[Ken Moffat]

On Sat, Oct 04, 2008 at 10:36:07PM +0000, mike wrote:
> Ken Moffat schrieb:
> >On Sat, Oct 04, 2008 at 12:46:55PM +0000, mike wrote:
> >  
> >>hi all
> >>
> >>i have a strange issue with libtool. when i compile with -m64, some 
> >>packages (kdelibs, kdebase, dbus-1-qt3 & others)want link wrong against 
> >>/usr/X11R7/lib/libXmu.so. and every this lib!?
> >>my 'workaround' for this was a temporarily symlink from /usr/X11/lib at 
> >>/usr/X11/lib64 during compile time. the 32libs are in /usr/X11/libb and 
> >>normaly /usr/X11/lib points to /usr/X11/libb.
> >>
> >>for example dbus-1-qt3:
> >>sed -i "/search_libs/s/lib/&64/g" configure &&
> >>CC="gcc ${BUILD64}" CXX="g++ ${BUILD64}" USE_ARCH=64 
> >>PKG_CONFIG_PATH="${PKG_CONFIG_PATH64}" \
> >>./configure --prefix=/usr --libdir=/usr/lib64 
> >>--with-qt-libraries=${QTDIR}/lib64 &&
> >>make
> >>..
> >>    
> > Probably, one or two commonly used libraries are causing the
> >problem.  If you can identify the _earliest_ package where you had
> >to do this, try running its configure without the extra overrides,
> >then look at the output (probably, config.log) to see which
> >package(s) decided that /usr/lib was wanted.  Unfortunately,
> >this part is tedious (hopefully, you can search for 'lib/' to skip
> >over the correct lib64 references).
> >
> > Then, look through the configure script to find *how* it searches
> >for this package (often, but not always, using pkgconfig).  I've
> >seen the *reverse* situation (32-bit libraries generally needing
> >overrides), but that was caused by not having wrapped versions of
> >-config programs.  I think I had something similar (again, not
> >necessarily libtool-related) on my first multilib system, but never
> >traced why - in those days I was content to just get it to work.
> >
> > But first, please check the xmu.pc and xmuu.pc pkgconfig files for
> >both sizes, to make sure they are correct, and in the correct
> >directories, and also check that your scripts are using the correct
> >PKG_CONFIG_PATH whenever you change from/to 32/64-bit.
> >
> > BTW, I'm curious why you put xorg into /usr/X11R7 instead of just
> >/usr ?
> >
> >ĸen
> >  
> xmu.pc and xmuu.pc are on the correct place and with correct content.  
> PKG_CONFIG_PATH is also ok.
> so i looked  in configure and makefile.am and so on.
 For the moment, all you need to look at is what configure decided
to do (config.log, both the values set at the end and the tests
(with line numbers) which caused them).  Personally, libtool scares
me to death (we can create dynamic libs without it, so it just adds
confusion and obfuscation on linux).
> this are strange autoconf people...
> the only one that i found  was the libtool is more friendly without 
> '--silent' flag:
> 
> /bin/sh ./libtool --tag=CXX --mode=link gcc -m64  -Wall -W 
> -Wpointer-arith -O2 -fno-exceptions -fno-check-new -fno-common    -o 
> dbusxml2qt3 -L/opt/qt/lib64 classgen.o main.o methodgen.o -lqt-mt  -lz 
> -lpng -lz -lm -lXext -lX11  -lSM -lICE -lpthread -L/usr/X11R7/lib64 
> -L/usr/X11R7/lib64
> gcc -m64 -Wall -W -Wpointer-arith -O2 -fno-exceptions -fno-check-new 
> -fno-common -o dbusxml2qt3 classgen.o main.o methodgen.o  
> -L/opt/qt/lib64 /opt/qt-3.3.8/lib64/libqt-mt.so -L/usr/lib64 
> -L/usr/X11R7/lib64 -lmysqlclient
 [ I'll break your line here, it looks ok up to libmysqlclient ]
> -lGL /usr/X11R7/lib/libXmu.so
> /usr/X11R7/lib/libXi.so /usr/X11R7/lib/libXrender.so 
> /usr/X11R7/lib/libXrandr.so /usr/X11R7/lib/libXcursor.so 
> /usr/X11R7/lib/libXinerama.so /usr/X11R7/lib/libXft.so 

 This might be one whole chain, for libXft.so.  That is one of the
libraries that uses a program to report how it is to be linked.
Please try

 USE_ARCH=64 xft-config --libs

> /usr/lib64/libfreetype.so /usr/lib64/libfontconfig.so 
> /usr/X11R7/lib/libXext.so /usr/X11R7/lib/libX11.so 
> /usr/X11R7/lib/libSM.so /usr/X11R7/lib/libICE.so
 [ breaking another line ]
 I was going to say, please also check what is in the 64-bit
version of ice.pc, but then I saw ...
> /usr/lib64/libpng12.so 
> -lz -lm /usr/X11R7/lib64/libXext.so /usr/X11R7/lib64/libX11.so 
> /usr/X11R7/lib64/libxcb-xlib.so /usr/X11R7/lib64/libxcb.so 
> /usr/X11R7/lib64/libXau.so /usr/X11R7/lib64/libXdmcp.so -ldl 
> /usr/X11R7/lib64/libSM.so -luuid /usr/X11R7/lib64/libICE.so -lpthread 
> -Wl,--rpath -Wl,/opt/qt-3.3.8/lib64 -Wl,--rpath -Wl,/usr/X11R7/lib 
> -Wl,--rpath -Wl,/usr/X11R7/lib64 -Wl,--rpath -Wl,/opt/qt-3.3.8/lib64 
> -Wl,--rpath -Wl,/usr/X11R7/lib -Wl,--rpath -Wl,/usr/X11R7/lib64
 Eek, a 64-bit libICE is correctly used here, probably by QT.

> /usr/X11R7/lib/libXmu.so: could not read symbols: File in wrong format
> 
> here you can see that the /usr/X11R7/lib64 is correctly set but someone 
> gives the local libtool wrong information about ALL X-libs. i tried some 
> env-vars - without look. its cracy. i think the wrong comes from -lqt-mt 
> but i don't know how it handled.
 What you might need to do is find *every* 64-bit .la file on the
system, and search them for '/usr/X11R7/lib ' (with the space, to
skip over lib64).  Off the top of my head, something like

 For L in /usr/lib64 /usr/X11R7/lib64 /opt/qt-3.3.8/lib64 ; do
	find $L -name '*.la' | xargs grep '/usr/lib '
 done

 I'm now suspicious of your xft-config program, but I note it would
only be 32-bit if you hadn't used the multiarch wrapper on it AND
had built 32-bit AFTER 64-bit, OR alternatively if you passed
USE_ARCH=32 to whatever was using it, or (perhaps) had
PKG_CONFIG_PATH pointing to /usr/X11R7/lib/pkgconfig.

 In my own multilib scripts I wrap USE_ARCH, PKG_CONFIG_PATH (and
also symlinks for tiffconf.h - I think that only matters on ppc64)
in a function, to help me keep it consistent.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce