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
