| 1 |
On 22 August 2010 18:41, Brent Busby <brent@×××××××××.org> wrote: |
| 2 |
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote: |
| 3 |
> |
| 4 |
>> So libtool creates the symlinks and the la file, thus satisfying the |
| 5 |
>> Makefile requirements, but never actually invokes gcc to build the |
| 6 |
>> library, so the symlinks are to a non-existent library. The libtool |
| 7 |
>> being used is an old in-tree version: |
| 8 |
> |
| 9 |
> [...] |
| 10 |
> |
| 11 |
>> # ../../libtool --version |
| 12 |
>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19) |
| 13 |
>> |
| 14 |
>> If just 'libtool' is invoked instead, |
| 15 |
>> |
| 16 |
>> # libtool --version |
| 17 |
>> libtool (GNU libtool) 2.2.10 |
| 18 |
> |
| 19 |
> [...] |
| 20 |
> |
| 21 |
>> the right thing is done and the library is built. |
| 22 |
> |
| 23 |
> That explains why Ladislav said earlier he was able to build the library |
| 24 |
> manually. |
| 25 |
> |
| 26 |
>> Note that libakode.so.2.0.0 is now there. On x86_64, I also had to |
| 27 |
>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link |
| 28 |
>> failed with a relocatable symbol error. |
| 29 |
> |
| 30 |
> In general terms (not specific to this particular package), what do you do |
| 31 |
> in the Makefile to fix that? I've been trying to fix the ebuild for |
| 32 |
> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the |
| 33 |
> same problem trying to build a shared object without -fPIC. There might be |
| 34 |
> a lot of older packages that need this out there, and I'd like to know what |
| 35 |
> the basic idea is to fix them myself. |
| 36 |
> |
| 37 |
|
| 38 |
It depends a lot on the build. With akode, I just hacked it into |
| 39 |
CXXFLAGS in the |
| 40 |
already-generated Makefile but to do it properly you'd need to patch |
| 41 |
akode/lib/Makefile.am |
| 42 |
to set AM_CXXFLAGS="-fPIC". |
| 43 |
|
| 44 |
>> I'd be interested to know when this was last known to build, as the |
| 45 |
>> in-tree libtool is clearly buggy. |
| 46 |
> |
| 47 |
> It worked for me earlier this year on x86_64, but using GCC 4.3, and before |
| 48 |
> the policy switch to libtool with '--as-needed'. I don't know if it was the |
| 49 |
> compiler switch or the new libtool options that made the difference, but I'd |
| 50 |
> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99% |
| 51 |
> the same. |
| 52 |
> |
| 53 |
|
| 54 |
The problem is that it never even calls gcc. From running strace on |
| 55 |
the libtool call: |
| 56 |
|
| 57 |
# cat /tmp/strace |grep 'execve('|awk '{print $2}'|sort|uniq |
| 58 |
execve("/bin/expr", |
| 59 |
execve("/bin/grep", |
| 60 |
execve("/bin/ln", |
| 61 |
execve("/bin/rm", |
| 62 |
execve("/bin/sed", |
| 63 |
execve("/bin/sh", |
| 64 |
execve("/bin/tr", |
| 65 |
|
| 66 |
No gcc. I've been through the libtool script quite a bit (with the |
| 67 |
help of adding --debug to the call) but can't stop why it's choosing |
| 68 |
not to call gcc to do the actual link. |
| 69 |
|
| 70 |
> -- |
| 71 |
> + Brent A. Busby + "We've all heard that a million monkeys |
| 72 |
> + UNIX Systems Admin + banging on a million typewriters will |
| 73 |
> + University of Chicago + eventually reproduce the entire works of |
| 74 |
> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, |
| 75 |
> + James Franck Institute + we know this is not true." -Robert Wilensky |
| 76 |
> |
| 77 |
> |
| 78 |
|
| 79 |
|
| 80 |
|
| 81 |
-- |
| 82 |
Andrew :-) |
| 83 |
|
| 84 |
Free Java Software Engineer |
| 85 |
Red Hat, Inc. (http://www.redhat.com) |
| 86 |
|
| 87 |
Support Free Java! |
| 88 |
Contribute to GNU Classpath and the OpenJDK |
| 89 |
http://www.gnu.org/software/classpath |
| 90 |
http://openjdk.java.net |
| 91 |
|
| 92 |
PGP Key: 94EFD9D8 (http://subkeys.pgp.net) |
| 93 |
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |
Archives