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

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.

> --
> + 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