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.
