The current net-misc/curl-7.18.1 appears to have some sanity issues. *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.26, ltmain.sh = "1.5.26 Debian 1.5.26-1") *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. !!! Please attach the following file when seeking support: !!! /gentoo/tmp/portage/net-misc/curl-7.18.1/work/curl-7.18.1/config.log * * ERROR: net-misc/curl-7.18.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2576: Called econf 'src_compile' 'src_compile' '--enable-ldap' '--enable-ldaps' '--with-libidn' '--with-gssapi=/usr' '--with-libssh2' '--enable-ipv6' '--enable-http' '--enable-ftp' '--enable-gopher' '--enable-file' '--enable-dict' '--enable-manual' '--enable-telnet' '--enable-nonblocking' '--enable-largefile' '--enable-maintainer-mode' '--disable-sspi' '--without-krb4' '--without-spnego' '--disable-ares' '--without-ssl' '--with-gnutls' * ebuild.sh, line 513: Called die * The specific snippet of code: * die "econf failed" * The die message: * econf failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/net-misc:curl-7.18.1:20080401-151513.log'. * The ebuild environment file is located at '/gentoo/tmp/portage/net-misc/curl-7.18.1/temp/environment'.
Created attachment 147980 [details] config.log
Created attachment 147981 [details] emerge --info For completeness.
don't know how this escaped me. I though I did enough to get past it but obviously not. SOrry for the inconvience. package masked in the mean time. Suggestions. on fixes welcome.
it seems to be a common bug: see this thread from Mike Frysinger for a clear explanation: http://thread.gmane.org/gmane.linux.gentoo.devel/23449 . I'd like to test the fix but emerge installs curl-7.18.1 with no problems for me. I see 2 possibilities: 1) run elibtoolize later in the ebuild. I mean after eaclocal or eautoheader 2) If that still does not work, run "libtoolize --copy --force || die" before eautoconf step.
I have the same problem, and am posting my "emerge --info" also.
Here's my emerge --info. http://bugs.gentoo.org/attachment.cgi?id=147983
(In reply to comment #4) > it seems to be a common bug: see this thread from Mike Frysinger for a clear > explanation: http://thread.gmane.org/gmane.linux.gentoo.devel/23449 . > I'd like to test the fix but emerge installs curl-7.18.1 with no problems for > me. > I see 2 possibilities: > 1) run elibtoolize later in the ebuild. I mean after eaclocal or eautoheader > 2) If that still does not work, run "libtoolize --copy --force || die" before > eautoconf step. > I tried #2 and it compiled for me, but spit the following messages: * Running autoheader ... [ ok ] * QA Notice: 'libtoolize' called by src_unpack: net-misc/curl-7.18.1 * Use autotools.eclass instead of calling 'libtoolize' directly. * Running autoconf ...
(In reply to comment #7) > (In reply to comment #4) > > it seems to be a common bug: see this thread from Mike Frysinger for a clear > > explanation: http://thread.gmane.org/gmane.linux.gentoo.devel/23449 . > > I'd like to test the fix but emerge installs curl-7.18.1 with no problems for > > me. > > I see 2 possibilities: > > 1) run elibtoolize later in the ebuild. I mean after eaclocal or eautoheader > > 2) If that still does not work, run "libtoolize --copy --force || die" before > > eautoconf step. > > > > I tried #2 and it compiled for me, but spit the following messages: > > * Running autoheader ... > [ ok ] > * QA Notice: 'libtoolize' called by src_unpack: net-misc/curl-7.18.1 > * Use autotools.eclass instead of calling 'libtoolize' directly. > * Running autoconf ... > Considering QA warning, I think eautoreconf may fix the problem. I had a look at eautoreconf definition in autotools.eclass and it seems that it does "libtoolize --copy --force step". Moreover it also run eaclocal, eautoconf and eautoheader. So with this method, src-unpack() may look like this: src_unpack() { unpack ${A} cd "${S}" epatch "${FILESDIR}"/curl-7.17.0-strip-ldflags.patch /usr/bin/perl -i.bak -pe 's/\bmv +([^-\s])/mv -f $1/g' aclocal.m4 cp lib/config.h.in src/config.h.in eautoreconf eautomake }
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #4) > > > it seems to be a common bug: see this thread from Mike Frysinger for a clear > > > explanation: http://thread.gmane.org/gmane.linux.gentoo.devel/23449 . > > > I'd like to test the fix but emerge installs curl-7.18.1 with no problems for > > > me. > > > I see 2 possibilities: > > > 1) run elibtoolize later in the ebuild. I mean after eaclocal or eautoheader > > > 2) If that still does not work, run "libtoolize --copy --force || die" before > > > eautoconf step. > > > > > > > I tried #2 and it compiled for me, but spit the following messages: > > > > * Running autoheader ... > > [ ok ] > > * QA Notice: 'libtoolize' called by src_unpack: net-misc/curl-7.18.1 > > * Use autotools.eclass instead of calling 'libtoolize' directly. > > * Running autoconf ... > > > Considering QA warning, I think eautoreconf may fix the problem. I had a look > at eautoreconf definition in autotools.eclass and it seems that it does > "libtoolize --copy --force step". Moreover it also run eaclocal, eautoconf and > eautoheader. > So with this method, src-unpack() may look like this: > src_unpack() { > unpack ${A} > cd "${S}" > epatch "${FILESDIR}"/curl-7.17.0-strip-ldflags.patch > /usr/bin/perl -i.bak -pe 's/\bmv +([^-\s])/mv -f $1/g' aclocal.m4 > cp lib/config.h.in src/config.h.in > eautoreconf > eautomake > } > Okay, that worked here. Cleaner.
Two questions: 1. Why do you run eautomake after eautoreconf, when eautoreconf runs it anyway ? 2. What is the reason for this step: /usr/bin/perl -i.bak -pe 's/\bmv +([^-\s])/mv -f $1/g' aclocal.m4 Besides, this cp lib/config.h.in src/config.h.in seems pointless, cause those files seem to be the same before eutoreconf, the problem is that autoheader modifies only one of them (first from AC_CONFIG_HEADERS), maybe this step should be moved after eautoreconf. You should ask somebody, who knows more about autotools, about this behavior.
(In reply to comment #10) > Two questions: > 1. Why do you run eautomake after eautoreconf, when eautoreconf runs it anyway > ? You are right. I did not see that eautomake was run by eautoreconf. > 2. What is the reason for this step: > /usr/bin/perl -i.bak -pe 's/\bmv +([^-\s])/mv -f $1/g' aclocal.m4 The primary reason was due to bug #193149 > Besides, this > cp lib/config.h.in src/config.h.in > seems pointless, cause those files seem to be the same before eutoreconf, > the problem is that autoheader modifies only one of them (first from > AC_CONFIG_HEADERS), maybe this step should be moved after eautoreconf. You > should ask somebody, who knows more about autotools, about this behavior. > You are right I am very far from being an autotools expert. So any feedback from somebody who has autotools knowledge is welcome.
got away with a eautoreconf. curl-7.18.1 recommited. if no errors by tommorrow i'll unmask it. thanks all for you suggestions
unmasked and no comments that it doesn't work. sorry for the inconvenience caused.
