Bugzilla Bug 57224

He tried to clean some stuff up ... here is a patch
that refixes the arches messed up, and finishes cleaning up
some stuff.

-Brad

Created an attachment (id=35505) [edit]
patch for libtool 1.5.2-r5 ebuild

thanks brad, you've saved the day once again!

stick a fork in it

:-(  Sorry about the breakage.

In truth, though, the invocations of gnuconfig_update in the libtool ebuilds were really screwed up.  It appears that somebody thought that gnuconfig_update depends on current working directory.  That's the only explanation I can think of for this kind of stuff in the ebuild:

   cd ${OLD_S}
   use mips && gnuconfig_update

   cd ${S}
   use mips && gnuconfig_update

What they didn't realize was that OLD_S was being fixed by an earlier invocation of gnuconfig_update which overrode S in src_unpack.  The later calls to gnuconfig_update were superfluous already because they were all happening in ${S}!

Recently I gave gnuconfig_update the ability to accept a starting directory as the first parameter.  So in this case I have changed the libtool ebuilds to call

   gnuconfig_update ${WORKDIR}

at the end of src_unpack (after all patches are applied so that the patches aren't broken).  This updates the gnuconfig stuff for all the source directories under ${WORKDIR}.  I've tested all the versions to make sure it's right.

So... my apologies for borking it!  :-(  On the other hand... it's a lot better now :-)  (and thanks Brad and Tom for catching the problem and putting in an initial fix)

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