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

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