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