Hi Mike,
and welcome to libtool ;)
On Mon, Jul 24, 2006 at 07:40:53PM +0200, mike wrote:
> hi folk,
>
> multilib-environment x86_64-unknown-linux amd-opteron
> many others programms compile correctly. (major-servers, x-org; lynx, etc.)
> i try to build kde-3.5.3. the arts-package compile fine.
> the next step, (kdelibs) fails with:
[...]
> network/libkdecorenetwork.la svgicons/libkdesvgicons.la
> ../dcop/libDCOP.la ../libltdl/libltdlc.la -lXext -lresolv -lutil
> -L/usr/lib -lart_lgpl_2 -lm ../kdefx/libkdefx.la
^^^^^^^^^^ see end of my reply
> /usr/bin/ld: skipping incompatible /usr/lib/../lib/libresolv.so when
> searching for -lresolv
> /usr/bin/ld: skipping incompatible /usr/lib/../lib/libresolv.a when
> searching for -lresolv
> /usr/bin/ld: skipping incompatible /usr/lib64/../lib/libresolv.so when
> searching for -lresolv
> /usr/bin/ld: skipping incompatible /usr/lib64/../lib/libresolv.a when
> searching for -lresolv
> /usr/bin/ld: skipping incompatible /usr/lib/libresolv.so when searching
> for -lresolv
> /usr/bin/ld: skipping incompatible /usr/lib/libresolv.a when searching
> for -lresolv
[...]
> /usr/lib64/../lib/libstdc++.so: could not read symbols: File in wrong
> format
> collect2: ld returned 1 exit status
> make[4]: *** [libkdecore.la] Error 1
>
> whats wrong in my environment?
> any help aviable?
>
what we see above is that ld is picking up 32-bit libraries
(/usr/lib64/../lib is, of course, /usr/lib) and it doesn't like
them. So, I assume you are trying to build a 64-bit kde ?
[ if you are trying to build a 32-bit kde, either you didn't pass
CC="gcc ${BUILD32}", or more likely you forgot to pass CXX="g++
${BUILD32}", or perhaps BUILD32 is not set. The rest of this reply
assumes you are trying to build 64-bit. ]
If you look at any libtool script (I don't know if kde builds its
own libtool or uses the installed libtool) on multilib it is usually
extremely nasty in sys_lib_dlsearch_path_spec - mixing lib and
lib64. This would deter me from building in /opt or /usr/local,
although I'm sure it can be overridden.
From my original notes on lib64, I see I was building in /usr and I
had to specify (for ALL of kde, including arts)
--qt-libraries=/usr/lib64 (otherwise they didn't used to be found)
and --enable-libsuffix=64 (so that at runtime the .la files
lib64/kde can be found) as well as the normal --libdir=/usr/lib64.
Dunno if any of that will be relevant to you.
The immediate problem is that libtool is confused. Recently, I've
only really seen this when building 32-bit (gcc compiles with -m32,
then ld fails to link against 64-bit libraries). I can remember
seeing it on my original multilib build (my first /lib64 was _all_
64-bit), but I don't recall why it happened, and I can't now find
any scripts with workarounds for it.
There are three different ways of correcting libtool on multilb:
1. Pass LDFLAGS to configure, possibly
LDFLAGS='-L/lib64 -L/usr/lib64 -L/usr/X11/lib64 -L/opt/kde/lib64' or
something like that.
2. Persuade a configure script, if it allows, to use gcc for ld,
with LD='gcc ${BUILD64}'
3. Force ld to do the right thing by specifying LDEMULATION - in
this case your only possible value would be elf_x86_64 and you
probably need to pass it to 'make'.
However, looking again at your post I see the -L/usr/lib. I
strongly suspect that libart_lgpl is a 32-bit version in /usr/lib,
or else that one or more of your lib directories contains a mixture
of 32- and 64- bit libraries (the first time we build multilib, we
ALL do that sooner or later).
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
