libtool 2.2.4 calls eautoreconf in ${S}. libtool 2.2.6a calls eautoreconf there and in ${S}/libltdl Calling eautoreconf results in calling `libtoolize --force`, which is not the case with the bootstrap script that comes with libtoolize (./bootstrap). It takes care of calling eautoreconf and supplies a libtoolize-dummy that does nothing. That script should be called instead. That fact that libtool runs libtoolize in the ebuild (through eautoreconf) is causes problems in portage prefix (e.g. on osx). Quoting http://www.gentoo.org/proj/en/qa/autofailure.xml here (emphasis added) Many packages provide a single script, often called autogen.sh or bootstrap.sh that is uses to execute the tools in the order that upstream thinks it's the right one, often setting variables so that the right version of the tools is run (different versions of autotools often does not get along well). These scripts are, in general, *preferred* over other methods [..]
it does not call libtoolize
Created attachment 166364 [details] It does -- attaching build log for `ebuild libtool-2.2.6a.ebuild clean unpack` libtoolize is called glibtoolize on osx
Reopening. See the above attachment.
the ebuild is correct. you're simply pointing out a bug in the Darwin code. Fabian: you'll want to review _elibtoolize() in autotools.eclass
It's not a prefix issue. In libtool's ebuild, we do [[ ${CHOST} == *-darwin* ]] && myconf="--program-prefix=g" and in autotools.eclass (both in _elibtoolize and eautoreconf) we do [[ ${CHOST} == *-darwin* ]] && LIBTOOLIZE="glibtoolize" with LIBTOOLIZE defaulting to libtoolize on every other architecture. This is all perfectly fine and unrelated to the bug. Please re-assign to base-system@gentoo.org
The whole problem seems to come from the fact, that there doesn't seem to be a way to skip _elibtoolize during eautoreconf. In nearly all cases it would probably be a very wrong thing to do, but here things break unless it's skipped.
ebuild does LIBTOOLIZE=true and that works... unless libtoolize is called glibtoolize.
so we're using the variable LIBTOOLIZE although we shouldn't be since it's defined somewhere else? this is horrible. where is it defined?
Created attachment 166563 [details, diff] exemplary diff against autotools.eclass No that's not it. I've applied this patch and the output turns out to be exactly the same. In a nutshell, the bug is not related to messing with the variable LIBTOOLIZE.
Maybe I misunderstood something, but still that patch makes things worse. Without that patch, as long as we're not on a darwin host, setting LIBTOOLIZE to true lets us skip it. With this patch, we can't skip it regardless of the host.
Thanks Rafał for finally making me understand why it only fails on Darwin. We should indeed not "clobber" with LIBTOOLIZE in a way that breaks this, like Mike said.
I patched stuff not to override LIBTOOLIZE now, and only change the value to set "if unset" to include the g on Darwin. This should do it. Please test.
Works now. Didn't realize LIBTOOLIZE is set in the ebuild (d'oh).
Fabian: any reason you arent checking this fixes into the main gentoo tree ?
I don't have any good reason apart from not wanting to pollute gentoo-x86 with prefix-specific bits that gentoo-x86 folk might not understand (and remove).
