1 |
On 22 August 2010 19:26, Ladislav Laska <ladislav.laska@×××××.com> wrote: |
2 |
> Hey thanks! This fixes it, but I'm not sure how to fix it properly. A |
3 |
> simple solution is to just call libtool directly (everyone should have |
4 |
> it installed), but I don't think it's right: |
5 |
> |
6 |
> I just tried it and make file with error: |
7 |
> kangaroo lib # make |
8 |
> make all-am |
9 |
> make[1]: Entering directory |
10 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib' |
11 |
> /bin/sh libtool --silent --tag=CXX --mode=link i686-pc-linux-gnu-g++ |
12 |
> -O2 -pipe -march=prescott -Wl,-O1 -Wl,--as-needed -o libakode.la |
13 |
> -rpath /usr/lib -no-undefined -Wl,--no-undefined |
14 |
> -Wl,--allow-shlib-undefined -version-info 2:0:0 bytebuffer.lo |
15 |
> audiobuffer.lo pluginhandler.lo decoderpluginhandler.lo |
16 |
> resamplerpluginhandler.lo sinkpluginhandler.lo encoderpluginhandler.lo |
17 |
> fast_resampler.lo crossfader.lo volumefilter.lo localfile.lo |
18 |
> mmapfile.lo wav_decoder.lo auto_sink.lo void_sink.lo converter.lo |
19 |
> buffered_decoder.lo player.lo magic.lo -lpthread -lltdl |
20 |
> i686-pc-linux-gnu-g++: |
21 |
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crti.o: No such file or |
22 |
> directory |
23 |
> i686-pc-linux-gnu-g++: |
24 |
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtbeginS.o: No such file or |
25 |
> directory |
26 |
> i686-pc-linux-gnu-g++: /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/crtendS.o: |
27 |
> No such file or directory |
28 |
> i686-pc-linux-gnu-g++: |
29 |
> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or |
30 |
> directory |
31 |
> make[1]: *** [libakode.la] Error 1 |
32 |
> make[1]: Leaving directory |
33 |
> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib' |
34 |
> make: *** [all] Error 2 |
35 |
> |
36 |
> This is correct, those files does not exist, since I don't have gcc |
37 |
> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config |
38 |
> and it still throws this error. After rebuilding libtool, it worked |
39 |
> like a charm. So this leads me to think that gcc version is somehow |
40 |
> hardcoded in libtool? But that's just stupid, it can't be. |
41 |
> |
42 |
|
43 |
It is. Re-emerging libtool fixed the same issue for me. |
44 |
|
45 |
libtool is rarely used directly like this. Usually a libtool script |
46 |
is generated for the particular setup. This is why you don't see the |
47 |
same libtool failure in normal portage builds. |
48 |
|
49 |
The one in akode is generated by admin/ltmain.sh |
50 |
|
51 |
> Do you have any suggestions? |
52 |
> |
53 |
> Regards Ladislav Laska |
54 |
> S pozdravem Ladislav Laska |
55 |
> --- |
56 |
> xmpp/jabber: ladislav.laska@××××××.cz |
57 |
> |
58 |
> |
59 |
> |
60 |
> On Sun, Aug 22, 2010 at 7:41 PM, Brent Busby <brent@×××××××××.org> wrote: |
61 |
>> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote: |
62 |
>> |
63 |
>>> So libtool creates the symlinks and the la file, thus satisfying the |
64 |
>>> Makefile requirements, but never actually invokes gcc to build the |
65 |
>>> library, so the symlinks are to a non-existent library. The libtool |
66 |
>>> being used is an old in-tree version: |
67 |
>> |
68 |
>> [...] |
69 |
>> |
70 |
>>> # ../../libtool --version |
71 |
>>> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19) |
72 |
>>> |
73 |
>>> If just 'libtool' is invoked instead, |
74 |
>>> |
75 |
>>> # libtool --version |
76 |
>>> libtool (GNU libtool) 2.2.10 |
77 |
>> |
78 |
>> [...] |
79 |
>> |
80 |
>>> the right thing is done and the library is built. |
81 |
>> |
82 |
>> That explains why Ladislav said earlier he was able to build the library |
83 |
>> manually. |
84 |
>> |
85 |
>>> Note that libakode.so.2.0.0 is now there. On x86_64, I also had to |
86 |
>>> patch the Makefile to add -fPIC to the CFLAGS otherwise the link |
87 |
>>> failed with a relocatable symbol error. |
88 |
>> |
89 |
>> In general terms (not specific to this particular package), what do you do |
90 |
>> in the Makefile to fix that? I've been trying to fix the ebuild for |
91 |
>> games-fps/quakeforge on x86_64 (bug #294388), which seems to run into the |
92 |
>> same problem trying to build a shared object without -fPIC. There might be |
93 |
>> a lot of older packages that need this out there, and I'd like to know what |
94 |
>> the basic idea is to fix them myself. |
95 |
>> |
96 |
>>> I'd be interested to know when this was last known to build, as the |
97 |
>>> in-tree libtool is clearly buggy. |
98 |
>> |
99 |
>> It worked for me earlier this year on x86_64, but using GCC 4.3, and before |
100 |
>> the policy switch to libtool with '--as-needed'. I don't know if it was the |
101 |
>> compiler switch or the new libtool options that made the difference, but I'd |
102 |
>> imagine it's the latter, since GCC 4.3 and 4.4 are supposed to act about 99% |
103 |
>> the same. |
104 |
>> |
105 |
>> -- |
106 |
>> + Brent A. Busby + "We've all heard that a million monkeys |
107 |
>> + UNIX Systems Admin + banging on a million typewriters will |
108 |
>> + University of Chicago + eventually reproduce the entire works of |
109 |
>> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, |
110 |
>> + James Franck Institute + we know this is not true." -Robert Wilensky |
111 |
>> |
112 |
>> |
113 |
> |
114 |
> |
115 |
|
116 |
|
117 |
|
118 |
-- |
119 |
Andrew :-) |
120 |
|
121 |
Free Java Software Engineer |
122 |
Red Hat, Inc. (http://www.redhat.com) |
123 |
|
124 |
Support Free Java! |
125 |
Contribute to GNU Classpath and the OpenJDK |
126 |
http://www.gnu.org/software/classpath |
127 |
http://openjdk.java.net |
128 |
|
129 |
PGP Key: 94EFD9D8 (http://subkeys.pgp.net) |
130 |
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 |