Re: [gentoo-desktop] Re: kde-sunset: new akode build problems

[Ladislav Laska]

Hey thanks! This fixes it, but I'm not sure how to fix it properly. A
simple solution is to just call libtool directly (everyone should have
it installed), but I don't think it's right:

I just tried it and make file with error:
kangaroo lib # make
make  all-am
make[1]: Entering directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
/bin/sh libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++
-O2 -pipe -march=prescott   -Wl,-O1 -Wl,--as-needed -o libakode.la
-rpath /usr/lib -no-undefined -Wl,--no-undefined
-Wl,--allow-shlib-undefined -version-info 2:0:0  bytebuffer.lo
audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo
resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo
fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo
mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo
buffered_decoder.lo player.lo magic.lo -lpthread -lltdl
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crti.o: No such file or
directory
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtbeginS.o: No such file or
directory
i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtendS.o:
No such file or directory
i686-pc-linux-gnu-g++:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or
directory
make[1]: *** [libakode.la] Error 1
make[1]: Leaving directory
`/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib'
make: *** [all] Error 2

This is correct, those files does not exist, since I don't have gcc
4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config
and it still throws this error. After rebuilding libtool, it worked
like a charm. So this leads me to think that gcc version is somehow
hardcoded in libtool? But that's just stupid, it can't be.

Do you have any suggestions?

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@××××××.cz



On Sun, Aug 22, 2010 at 7:41 PM, Brent Busby <brent@×××××××××.org> wrote:
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote:
>
>> So libtool creates the symlinks and the la file, thus satisfying the
>> Makefile requirements, but never actually invokes gcc to build the
>> library, so the symlinks are to a non-existent library.  The libtool
>> being used is an old in-tree version:
>
> [...]
>
>> # ../../libtool --version
>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
>>
>> If just 'libtool' is invoked instead,
>>
>> # libtool --version
>> libtool (GNU libtool) 2.2.10
>
> [...]
>
>> the right thing is done and the library is built.
>
> That explains why Ladislav said earlier he was able to build the library
> manually.
>
>> Note that libakode.so.2.0.0 is now there.  On x86_64, I also had to
>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link
>> failed with a relocatable symbol error.
>
> In general terms (not specific to this particular package), what do you do
> in the Makefile to fix that?  I've been trying to fix the ebuild for
> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the
> same problem trying to build a shared object without -fPIC.  There might be
> a lot of older packages that need this out there, and I'd like to know what
> the basic idea is to fix them myself.
>
>> I'd be interested to know when this was last known to build, as the
>> in-tree libtool is clearly buggy.
>
> It worked for me earlier this year on x86_64, but using GCC 4.3, and before
> the policy switch to libtool with '--as-needed'.  I don't know if it was the
> compiler switch or the new libtool options that made the difference, but I'd
> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99%
> the same.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + UNIX Systems Admin     +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
> + James Franck Institute +  we know this is not true." -Robert Wilensky
>
>