Bugzilla Bug 73140

In Gentoo ~x86 there was an upgrate to libtool 1.5.10 yesterday.

I recompiled heimdal today and noticed that the libraries didn't have .so in their name and so everything broke (the heimdal rebuild runs elibtoolize). back to 1.5.2-r7 and it works again.

This happened before with other upgrades beyond 1.5.2 which where then retired.


Reproducible: Always
Steps to Reproduce:

Yes, I have this problem too. I haven't attributed it to libtool yet. However,
what happens is, when I try to emerge any of the GTK# bindings, they all create
files in /usr/lib like libgtksharpglue instead of libgtksharpglue.so.
That breaks every application that depends on GTK# bindings.

*** Bug 73322 has been marked as a duplicate of this bug. ***

oddly fam works fine as do most apps

i'll mask 1.5.10 until this can be tracked down

Downgraded libtool and re-emerged all the newest sharp-libraries. Now all gtk#
applications work fine.

*** Bug 73684 has been marked as a duplicate of this bug. ***

*** Bug 73563 has been marked as a duplicate of this bug. ***

Bug 73563 occurs with libtool-1.5.2-r7/r5 as well so it doesn't appear to be a
duplicate of this bug.

ok, after talking to azarah, we've decided we're not going to hack around this
anymore

this is a bug in heimdal, not in libtool

you cant run `aclocal` and update the aclocal.m4 with the system's libtool.m4
w/out running `libtoolize` to update the local libtool/ltmain.sh files too

we've updated libtool-1.5.10-r1 to perform a version sanity check ... i imagine
a bunch of packages will fail this sanity check, but oh well ... this is a
problem that should have been addressed by maintainers, not libtool

So basically your happy to break application to suite the purpose of libtool...
 This isin't what gentoo is all about. Secondlly heimdal on packages.gentoo.org
has being listed as stable, that has to be changed.

I have updated app-crypt/heimdal-0.6.3-r1 with an extra elibtoolize call at
seemant's request (as he has no CVS whilst on holiday). I have tested this with
libtool 1.5.10-r2 and 1.5.2-r7, in each case heimdal compiles as expected.

The fix by Marcus Hanwell (2005-01-18) of calling elibtoolize a second time is
giving me trouble.

elibtoolize is NOT idempotent; in particular, it will not run
    libtoolize --copy --force
if the portage patch fails to apply (which is likely to happen if it has already
been applied, for example during the first run of elibtoolize).

I've replaced the second elibtoolize call with a simple
    libtoolize --copy --force
and the build now proceeds. Whether this is the right solution for everyone
I don't know.

I'm not sure why this wasn't caught earlier. Did elibtoolize itself change
its behaviour recently?

The second call to elibtoolize breaks the build process. Comment #11's solution
seems to work.

*** Bug 73684 has been marked as a duplicate of this bug. ***