Re: Re: kde-sunset: new akode build problems

On 22 August 2010 19:26, Ladislav Laska <[email protected]> wrote:
> 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.
>

It is. Re-emerging libtool fixed the same issue for me.

libtool is rarely used directly like this.  Usually a libtool script
is generated for the particular setup.  This is why you don't see the
same libtool failure in normal portage builds.

The one in akode is generated by admin/ltmain.sh

> Do you have any suggestions?
>
> Regards Ladislav Laska
> S pozdravem Ladislav Laska
> ---
> xmpp/jabber: [email protected]
>
>
>
> On Sun, Aug 22, 2010 at 7:41 PM, Brent Busby <[email protected]> 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
>>
>>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8