the ebuild runs `elibtoolize` for no reason ... * Patching ${S}/ltmain.sh ... * Could not apply portage.patch! * Please verify that it is not needed. * Cannot apply any patch, running libtoolize... when all the patches fail, elibtoolize runs `libtoolize --copy --force` which then triggers a libtool version mismatch between configure and ltmain.sh
*** Bug 74751 has been marked as a duplicate of this bug. ***
*** Bug 75240 has been marked as a duplicate of this bug. ***
*** Bug 80076 has been marked as a duplicate of this bug. ***
I have been testing the gnome2 eclass without the elibtoolize call since this bug was reported. I haven't run into any problems, and have built at least everything in the gnome-desktop release. I don't see a need to call elibtoolize for every package that uses this eclass, and think it should be done on a per package basis when needed. Comments welcome..
*** Bug 84556 has been marked as a duplicate of this bug. ***
I am seeing a similar error when trying to build mono from source: checking for strip... strip checking for correct ltmain.sh version... no *** Gentoo sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.14, ltmain.sh = 1.4.2) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. configure: error: /bin/sh './configure' failed for libgc
The emerge of Gnome I'm trying to complete is apparently coughing up for the same reason on lcms-1.13. Tried a proposed fix to the libtool.m4 and ltmain.sh mismatch offered by the folks working with Mono to edit ltmain.sh to a matching version with libtool.m4. However, it still gives me the same as before since the emerge just messes with ltmain.sh again. Solution I found is to add after src_compile() in the ebuild in /usr/portage/media-libs/lcms/ the following: aclocal libtoolize --force --copy autoconf Then run "ebuild [full path to the ebuild file] digest" followed by "ebuild [full path to the ebuild file] compile", then a "ebuild [full path to the ebuild file] install, and finally "ebuild [full path to the ebuild file] qmerge". So now I have no more: *** Gentoo Sanity Check Failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.16, ltmain.sh = 1.5) *** Please run: libtoolize --copy --force if appropriate please contact the maintainer... !!! Please attach the config.log... !!! /var/tmp/portage/lcms-1.13... !!! ERROR media-libs/lcms-1.13 failed. !!! Function econfig, Line 485, Exitcode 0 !!! econfig failed. !!! If you need support...
elibtoolize is now conditionalized in the eclass on the setting of the ELTCONF var. This is because some ebuilds still do pass some options (scim*/gal/evolution/libgtkhtml) which were important to have at the time, these individual cases should be investigated and obsoleted before the use of elibtoolize can be completely dropped.
and closing..
Got reports that disabling this caused '/var/tmp/portage*' paths in .la files, reverted the change for until this gets figured out.
*** Bug 96635 has been marked as a duplicate of this bug. ***
I added the proper patch for libtool 1.4.1 (what all versions of libxmlpp I checked in portage at least use) some time back, so this should be a non issue, and can be closed.
i added foser's change back in our svn overlay for more testing.
(In reply to comment #14) > i added foser's change back in our svn overlay for more testing. > Err, removing the elibtoolize call again? Please do not, it is needed. What I meant, was that it should not fail on patching any more (comment #0), so no need to remove it in the first place.
FWIW elibtoolize now is forced by eautoreconf, too (and it's skipped when not required anyway), as it's an important requirement for example for Gentoo/FreeBSD to get decently-named libraries (and has to be run with final autoconf output).
I dont see why ... all the patches are already in our libtool.
Just in case anybody wondered .. elibtoolize (which might rather have been called elibtoolpatch or something), have nothing in common with libtoolize - its purely to make sure needed patches are applied to shipped versions of libtool without the pain of running libtoolize and all the pain it might cause due to lack of knowledge or missing macro's ...
reverted change in svn, resolving since the original issue has been fixed. Thanks az
(In reply to comment #17) > I dont see why ... all the patches are already in our libtool. > Err, nm me, I missed the FBSD bit ... Sorry Diego.
There are a few patches applied also if libtoolize is already called (see example on KDE's packages I'm testing now): * Running elibtoolize in: kpdf-3.5.1/admin * Applying portage-1.4.1.patch ... * Applying max_cmd_len-1.5.0.patch ... * Applying sed-1.4.3.patch ... Also, some packages uses an internal copy of libtool.m4 that makes libtoolize a no-op for Gentoo/FreeBSD. Better safe than sorry, I'd rather force it :)
(In reply to comment #21) > There are a few patches applied also if libtoolize is already called (see > example on KDE's packages I'm testing now): > > * Running elibtoolize in: kpdf-3.5.1/admin > * Applying portage-1.4.1.patch ... > * Applying max_cmd_len-1.5.0.patch ... > * Applying sed-1.4.3.patch ... > They get applied twice :/ Should probably add a test for them ... although the max_cmd_len and sed ones does not matter if they do. The portage one is wrong though, and might cause issues - guess I will need to add a test to see if we should apply or not.
Should be fixed now for portage patch at least .. some extra eyes would be welcome.
Okay portage is skipped... I'm wondering how it can apply the same patch twice, and why it applies the patch 1.5.0 instead of 1.5.20 for max_cmd_len. (by the way, seems like KDE packages has the faulty libtool.m4 provided..).
(In reply to comment #24) > Okay portage is skipped... I'm wondering how it can apply the same patch twice, > and why it applies the patch 1.5.0 instead of 1.5.20 for max_cmd_len. > (by the way, seems like KDE packages has the faulty libtool.m4 provided..). > Hmm, yeah, might add a find in the _elibtoolize func to search specified include dirs for included libtool.m4's, and rm them, else we might run into issues, as the specified includes for aclocal are searched before the system includes, which might (and probably will in most cases) cause a version mismatch ...
