Ken Moffat schrieb:
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
for L in /usr/lib64 /usr/X11R7/lib64 /opt/qt-3.3.8/lib64 ; do
find $L -name '*.la' | xargs grep '/usr/lib '
done
gives nothing.
USE_ARCH=64 xft-config --libs
gives: -L/usr/X11R7/lib64 -lXft -lX11 -lfreetype -lz -lfontconfig
-L/usr/X11R7/lib64 -lXrender -lX11
its scary...
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
