No. The akode ships its own, old, version (generated specifically for akode) which is buggy. We have tried to hack the makefile to use system version of libtool - this works most of the time (in case gcc was updated after libtool was merged, in my case libtool failed because of it - in this case, re-emergin libtool fixed the problem and the hack worked).
However, I don't know where is the problem and neither Andrew seems to know. As Andrew found out, it seems to be a bug in configuration, since regenerating libtool script does not help (I'm not an expert, but it seems that if you run system's libtool, it does not read scripts in project directory and 'just does something') - that's why hack works and anything else doesn't. Unfortunately, we can't use this hack in ebuild, since it requires libtool rebuild in most cases. Regards Ladislav Laska S pozdravem Ladislav Laska --- xmpp/jabber: [email protected] On Fri, Aug 27, 2010 at 8:41 PM, Brent Busby <[email protected]> wrote: > On Sun, 22 Aug 2010, Dr Andrew John Hughes wrote: > > [...] >>> >>> /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../crtn.o: No such file or >>> directory >>> make[1]: *** [libakode.la] Error 1 >>> make[1]: Leaving directory >>> `/var/tmp/portage/media-libs/akode-2.0.2/work/akode-2.0.2/akode/lib' >>> make: *** [all] Error 2 >>> >>> This is correct, those files does not exist, since I don't have gcc >>> 4.4.3 installed (had it once, now I have 4.4.4). I tried gcc-config >>> and it still throws this error. After rebuilding libtool, it worked >>> like a charm. So this leads me to think that gcc version is somehow >>> hardcoded in libtool? But that's just stupid, it can't be. >>> >> >> It is. Re-emerging libtool fixed the same issue for me. >> >> libtool is rarely used directly like this. Usually a libtool script >> is generated for the particular setup. This is why you don't see the >> same libtool failure in normal portage builds. >> >> The one in akode is generated by admin/ltmain.sh > > I may not have understood correctly, but I tried re-emerging the system > package for libtool, and it didn't help with the akode problem. It sounds > like you're saying that the source tarball for akode ships with its own > bundled (and old) version of libtool, but if it would just use the newer > version provided by the system, the build would succeed. > > How did you fix that by re-emerging the system libtool though? > > -- > + 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 > >
