On 22 August 2010 20:19, Dr Andrew John Hughes <[email protected]> wrote: > On 22 August 2010 18:41, 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. >> > > It depends a lot on the build. With akode, I just hacked it into > CXXFLAGS in the > already-generated Makefile but to do it properly you'd need to patch > akode/lib/Makefile.am > to set AM_CXXFLAGS="-fPIC". > >>> 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. >> > > The problem is that it never even calls gcc. From running strace on > the libtool call: > > # cat /tmp/strace |grep 'execve('|awk '{print $2}'|sort|uniq > execve("/bin/expr", > execve("/bin/grep", > execve("/bin/ln", > execve("/bin/rm", > execve("/bin/sed", > execve("/bin/sh", > execve("/bin/tr", > > No gcc. I've been through the libtool script quite a bit (with the > help of adding --debug to the call) but can't stop why it's choosing > not to call gcc to do the actual link. >
It's not the libtool version but something to do with how the build is generating the script. Using the system 2.2.10 works but altering the build (comment out dnl AM_PROG_LIBTOOL and add LT_INIT in admin/acinclude.m4.in then run make -f admin/Makefile.common; libtoolize and configure again) to generate a 2.2.10 script rather than 1.5 still fails. >> -- >> + 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 > -- 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
