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
