I am compiling an external (non Gentoo) application ( http://www.systella.fr/~bertrand/rpl2/ ) for which I wrote an ebuild to make updates easier. since doublehp-dhp/rpl2-4.0.0_pre7 maintainer discovered a bug in libtoolise. In pre8, I now get this message: checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.26, ltmain.sh = 1.5.18) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. This means: developper thinks Gentoo's libtool is broken.
Created attachment 159611 [details] my rpl2-4.0.0_pre8.ebuild
Created attachment 159613 [details] /tmp/emerge--info
Created attachment 159614 [details] /var/log/portage/sys-devel:libtool-1.5.26:20080705-114913.log libtool compile log
Created attachment 159619 [details] /var/log/portage/doublehp-dhp:rpl2-4.0.0_pre8:20080705-113521.log I know this is not a Gentoo ebuild, still, this libtool problem could become a problem for other official ebuilds in the future ...
Who else thinks this should be closed as invalid ? Anyway, even if I don't fully understand why Gentoo adds this check, I think it's there for a good reason and that developer shouldn't make guesses about things he/she doesn't understand. This is something that fits more into a forum than bugzilla. Try if adding eautoreconf in src_unpack helps, but as I don't feel like downloading ca. 16MB of something I won't use and that you seemed to need to run configure from different dir than the current this may not be so easy.
That check was here for ages and IIRC it's something needed due to FreeBSD (devs, feel free to correct me on this).
(In reply to comment #5) > Who else thinks this should be closed as invalid ? > Anyway, even if I don't fully understand why Gentoo adds this check, > I think it's there for a good reason and that developer shouldn't > make guesses about things he/she doesn't understand. You are wrong, things are reverse way: Gentoo does NOT check things, and developper complains about things he is 100% sure about ! He used to assume distros are doing things right, and encontoured a problem because distros dont ! Bertrand Joel is a very good devlopper. He added this check because libtool as many failures, and because those failures break his application on many systems. He only used to assume that applications respect their API, and that programs he did not write are written according to RFC, and he is now tired that these assumptions are wrong. He found many bugs in almost all libs he is calling, on almost all architectures and distros; this week, he found Yet An Other Bug in libtool (far from the first one). I helped him several times fixing bugs, in his app, or writing report about other apps bugs. So, I know what I talk about, and that Bertrand knows what it does when he complains about libtool. > This is something that fits more into a forum than bugzilla. > Try if adding eautoreconf in src_unpack helps, but as I don't feel like > downloading ca. 16MB of something I won't use and that you seemed to need > to run configure from different dir than the current this may not be so easy. I am just trying to help Gentoo fix libtool before this libtool bug breaks an other app. Cause as you know, anything that is broken WILL produce a crash soon or late. The problem is very simple, and libtool maintainer should be able to fix very quickly ... once assigned to the right person :)
Well, that check was added for a very good reason. See bug 73563 for an explanation. And while this is not a standard check, it means it's a sane one and probably your bug is simply caused by a non-standard way libtool was added to this package. And I was NEVER questioning the competence of that developer regarding his own package, only doubting if he/she added libtool to his/her project in a way that autotools devs recommend.
After all if `./autoreconf` doesn't work it's probably non-standard and is a specific package problem, not a distribution one.
And I'm not saying 'libtool is perfect'.
INVALID, untill I do more testing ...
