Bugzilla Bug 40901

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 an attachment (id=25222) [edit]
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 an attachment (id=25359) [edit]
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 an attachment (id=25360) [edit]
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. ***