| 1 |
No. |
| 2 |
|
| 3 |
The akode ships its own, old, version (generated specifically for |
| 4 |
akode) which is buggy. We have tried to hack the makefile to use |
| 5 |
system version of libtool - this works most of the time (in case gcc |
| 6 |
was updated after libtool was merged, in my case libtool failed |
| 7 |
because of it - in this case, re-emergin libtool fixed the problem and |
| 8 |
the hack worked). |
| 9 |
|
| 10 |
However, I don't know where is the problem and neither Andrew seems to know. |
| 11 |
|
| 12 |
As Andrew found out, it seems to be a bug in configuration, since |
| 13 |
regenerating libtool script does not help (I'm not an expert, but it |
| 14 |
seems that if you run system's libtool, it does not read scripts in |
| 15 |
project directory and 'just does something') - that's why hack works |
| 16 |
and anything else doesn't. Unfortunately, we can't use this hack in |
| 17 |
ebuild, since it requires libtool rebuild in most cases. |
| 18 |
|
| 19 |
Regards Ladislav Laska |
| 20 |
S pozdravem Ladislav Laska |
| 21 |
--- |
| 22 |
xmpp/jabber: ladislav.laska@××××××.cz |
| 23 |
|
| 24 |
|
| 25 |
|
| 26 |
On Fri, Aug 27, 2010 at 8:41 PM, Brent Busby <brent@×××××××××.org> wrote: |
| 27 |
> On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote: |
| 28 |
> |
| 29 |
> [...] |
| 30 |
>>> |
| 31 |
>>> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or |
| 32 |
>>> directory |
| 33 |
>>> make[1]: *** [libakode.la] Error 1 |
| 34 |
>>> make[1]: Leaving directory |
| 35 |
>>> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib' |
| 36 |
>>> make: *** [all] Error 2 |
| 37 |
>>> |
| 38 |
>>> This is correct, those files does not exist, since I don't have gcc |
| 39 |
>>> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config |
| 40 |
>>> and it still throws this error. After rebuilding libtool, it worked |
| 41 |
>>> like a charm. So this leads me to think that gcc version is somehow |
| 42 |
>>> hardcoded in libtool? But that's just stupid, it can't be. |
| 43 |
>>> |
| 44 |
>> |
| 45 |
>> It is. Re-emerging libtool fixed the same issue for me. |
| 46 |
>> |
| 47 |
>> libtool is rarely used directly like this. Usually a libtool script |
| 48 |
>> is generated for the particular setup. This is why you don't see the |
| 49 |
>> same libtool failure in normal portage builds. |
| 50 |
>> |
| 51 |
>> The one in akode is generated by admin/ltmain.sh |
| 52 |
> |
| 53 |
> I may not have understood correctly, but I tried re-emerging the system |
| 54 |
> package for libtool, and it didn't help with the akode problem. It sounds |
| 55 |
> like you're saying that the source tarball for akode ships with its own |
| 56 |
> bundled (and old) version of libtool, but if it would just use the newer |
| 57 |
> version provided by the system, the build would succeed. |
| 58 |
> |
| 59 |
> How did you fix that by re-emerging the system libtool though? |
| 60 |
> |
| 61 |
> -- |
| 62 |
> + Brent A. Busby + "We've all heard that a million monkeys |
| 63 |
> + UNIX Systems Admin + banging on a million typewriters will |
| 64 |
> + University of Chicago + eventually reproduce the entire works of |
| 65 |
> + Physical Sciences Div. + Shakespeare. Now, thanks to the Internet, |
| 66 |
> + James Franck Institute + we know this is not true." -Robert Wilensky |
| 67 |
> |
| 68 |
> |
Archives