when I emerge media-libs/libao-0.8.4-r1 I get this (list stripped to relevant entries; .a files are removed). All the .so extensions are missing and so ogg123 and mpg321 won't work anymore: /usr/lib/libao.2 -> libao.2.1.2 /usr/lib/libao.2.1.2 /usr/lib/libao.la /usr/lib/ao/plugins-2/libalsa09 /usr/lib/ao/plugins-2/libalsa09.la /usr/lib/ao/plugins-2/libarts /usr/lib/ao/plugins-2/libarts.la /usr/lib/ao/plugins-2/libesd /usr/lib/ao/plugins-2/libesd.la /usr/lib/ao/plugins-2/liboss /usr/lib/ao/plugins-2/liboss.la /usr/lib/ao/plugins-2/libalsa09 /usr/lib/ao/plugins-2/libalsa09.la /usr/lib/ao/plugins-2/libarts /usr/lib/ao/plugins-2/libarts.la /usr/lib/ao/plugins-2/libesd /usr/lib/ao/plugins-2/libesd.la /usr/lib/ao/plugins-2/liboss /usr/lib/ao/plugins-2/liboss.la btw: ebuild should honour '-static' USE flag! Since I only want to use shared libs, .a files are crap. ;-) Reproducible: Always Steps to Reproduce: 1. emerge libao 2. ls -ls /usr/lib/libao.* /usr/lib/ao/plugins-2 Actual Results:
Created attachment 25222 [details] emerge info
what libtool version? with libtool 1.4 it works, with 1.5 it reproduces your behaviour.
ok ... here's what i've found ... i'm an autotool n00b so bare with me :p in libtool, library names are determined via variables like library_names_spec ... in libtool-1.4.3, it'd figure out the extension to add and then do so such that the final aclocal.m4 would actually have say '.so' in the file however, in libtool-1.5.2, they've broken the '.so' out into a variable (shared_ext) ... the problem is that aclocal.m4 refers to $shared_ext and expects that ltmain.sh do something like eval shared_ext=$shrext (where in our case, shrext=.so) in older ltmain.sh files, that variable isnt evaluated because it's never needed ... it seems that after unpacking the libao source and running aclocal/autoconf, we generate a new aclocal.m4 file that uses the new libtool.m4 file (which uses the shared_ext variable) but we never recreate ltmain.sh so it never sets up the $shared_ext variable the end result is the variables like library_names_spec do $shared_ext expecting it to have .so but instead has "" producing libraries like 'libao.2' instead of 'libao.so.2' the solution i think is to make sure we create ltmain.sh ... how we do that, i have no idea ;)
diff -u -b -B -u -r1.5 libao-0.8.4-r1.ebuild --- libao-0.8.4-r1.ebuild 28 Jan 2004 03:11:07 -0000 1.5 +++ libao-0.8.4-r1.ebuild 9 Feb 2004 03:42:12 -0000 @@ -1,6 +1,7 @@ # Copyright 1999-2004 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header: /home/cvsroot/gentoo-x86/media-libs/libao/libao-0.8.4-r1.ebuild,v 1.5 2004/01/28 03:11:07 spider Exp $ +inherit libtool DESCRIPTION="the audio output library" HOMEPAGE="http://www.xiph.org/ao/" @@ -25,6 +26,8 @@ epatch ${FILESDIR}/alsa-1.0.patch cd ${S} epatch ${FILESDIR}/${P}-esd.patch + cp /usr/share/libtool/ltmain.sh . + elibtoolize WANT_AUTOCONF=2.5 autoconf || die } Darkmere libao # qpkg -l libao |grep so - /usr/lib/ao/plugins-2/liboss.so /usr/lib/ao/plugins-2/libesd.so /usr/lib/ao/plugins-2/libalsa09.so /usr/lib/libao.so.2.1.2 /usr/lib/libao.so.2 -> libao.so.2.1.2 /usr/lib/libao.so -> libao.so.2.1.2 Darkmere libao # qpkg -v libtool -I sys-devel/libtool-1.5.2-r1 *
that made it work. its ugly as fsck though, and I'd not recommend it as a "solution".
azarah: so the trouble here is that the libtool.m4 that comes with 1.5.2 is pretty tightly bound to the ltmain.sh that comes with it ... so if we run autoconf/aclocal/etc... from now on, we're going to need to recreate ltmain.sh ... any thoughts/ideas on how best to tackle this ? spider had kind of the right idea ... i think the 'better' way of going about it is to run `rm ltmain.sh ; libtoolize` ...
In that case, how about just running 'libtoolize --copy --force' ? It needs to be verified for 1.4 though ...
What if you first remove ltmain.sh and then run libtoolize. That should recreate ltmain.sh
ok, I downgrade to libtool-1.4.3 for the time being. I think other ebuilds are also broken then and I don't want to risk a damaged system. you should mask libtool-1.5.2 till you have a solution!
yeah, just tested with 1.4.x and 1.5.x and in both cases, running `libtoolize -c -f` after patching configure.in and running `autoconf` allowed the package to be built correctly added fix to cvs
and you are sure, that you have fixed all ebuilds which have this effect?
Uhm, you guys do not give a guy a chance.
Created attachment 25359 [details, diff] libtool-1.5.2-libtool_m4-shared_ext.patch Fix is relatively easy after you figured out where to put it in the .m4. Basically check if we set $shared_ext to $shrext, if not, replace all $shared_ext with '.so'. Anybody care to test this patch? Works over here ...
Created attachment 25360 [details, diff] libtool-1.5.2-libtool_m4-shared_ext.patch Actually, this might be the better one, as it "should" be more generic.
I try to test it tomorrow. It's too late now to test (01:17 CET) ;)
i was treating this bug as a libao bug and not a general libtool bug ... i updated the libao bug and as such i considered the issue closed :P i guess your patch is nicer ;)
nicer? I think, this is the ONLY kind of fix we can accept! You don't know, how many ebuilds are affected by this libtool behavior! There's at least another bugzilla (fam if I remember right) about the libtool problem.
theres two other packages put into bugzilla with this problem and ive fixed them both how many packages are affected ? i dunno, none of the ones ive tested ;)
There are other issues as well. I noticed a few 'integer value expected' for some builds that also used older libtool, but ran autoconf (gtk+-1.0, esound, etc).
i tried the patch out on libao and fam and it worked as advertised libwww still needs to be updated to autoconf-2.5x to work, but i guess that's a different (unfixable) problem
ok, then commit all the patches and give it to the people. ;-)
-r2 fixes this bug, -r3 fixes the other issue I mentioned.
*** Bug 41278 has been marked as a duplicate of this bug. ***
