Bugzilla Bug 74669

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. ***

*** 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  ...