Summary: | net-dns/bind-9.4.2 libtool failure | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dan Coats <admin> |
Component: | New packages | Assignee: | Konstantin Arkhipov (RETIRED) <voxus> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexxy, bind+disabled, bugzilla, chris, cyrius, dennis.freise, eva, gentoo, graham, mmokrejs, pchrist |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 212763 | ||
Attachments: |
net-dns:bind-9.4.2:20080505-132337.log
Updated ebuild. note the double-run of eautoreconf (ugly) patch for configure.in, required by the updated ebuild Fixed ebuild, the correct way. |
Description
Dan Coats
2008-05-05 13:31:06 UTC
Same problem here Created attachment 151927 [details]
net-dns:bind-9.4.2:20080505-132337.log
*** Bug 218823 has been marked as a duplicate of this bug. *** Temporary workaround can be done by masking libtool-2.2.4 (in /etc/portage/package.mask) by adding =sys-devel/libtool-2.2.4 line and emerging libtool again. Tested on 5 machines, this solves our problem, but remember this is only TEMPORARY WORKAROUND *** Bug 220531 has been marked as a duplicate of this bug. *** (In reply to comment #4) > Temporary workaround can be done by masking libtool-2.2.4 (in > /etc/portage/package.mask) by adding =sys-devel/libtool-2.2.4 line and emerging > libtool again. > > Tested on 5 machines, this solves our problem, but remember this is only > TEMPORARY WORKAROUND > So if this is as you said TEMPORARY WORKAROUND, then why are you posting non-fixes ? Back on topic. As I don't have bind installed and its home site doesn't have online source browsing, I can't say much, but it looks like running eautoreconf in ${S}/lib/bind should fix it. Then again, maybe not. If they keep libtool files (specifically libtool.m4) somewhere, this is what messes up the rebuild, cause IIRC this error appears when ltmain.sh is updated and libtool.m4 stays old. (In reply to comment #7) > Then again, maybe not. > If they keep libtool files (specifically libtool.m4) somewhere, this is what > messes up the rebuild, cause IIRC this error appears when ltmain.sh is updated > and libtool.m4 stays old. Yes, it is there, included by aclocal.m4. I fixed it (for me) with an ugly hack (I'll attach it). Created attachment 152437 [details]
Updated ebuild. note the double-run of eautoreconf (ugly)
Created attachment 152439 [details, diff]
patch for configure.in, required by the updated ebuild
OK, if your hack works , then, while using your patch, try simply a single line of: AT_M4DIR="m4" WANT_AUTOCONF=2.5 AT_NO_RECURSIVE=1 eautoreconf (no die, as eutoreconf dies anyway, if it fails). And the point of it is, the version included in aclocal.m4 doesn't matter unless aclocal.m4 was not autogenerated by aclocal. The problem is that the content of the "m4" subdirectory is created by the first "libtoolize" run. You can see the following notices afterwards in the original: the libtoolize log shows: ***** libtoolize ***** ***** libtoolize --copy --force --install libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./config.guess' libtoolize: copying file `./config.sub' libtoolize: copying file `./install-sh' libtoolize: copying file `./ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' libtoolize: `/usr/share/aclocal/ltoptions.m4' libtoolize: `/usr/share/aclocal/ltversion.m4' libtoolize: `/usr/share/aclocal/ltsugar.m4' libtoolize: `/usr/share/aclocal/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' The patch does add the `AC_CONFIG_MACRO_DIR([m4])' to configure.in. The cat m4/* does the first part, which is only possible after the libtoolize run created the files. Your idea does sadly not work, just tried it. Adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in changes the path to m4/ instead of /usr/share/aclocal. Forgot to mention that, It says 'Consider adding' not 'You must add' And of course comment #14 is completely wrong: AC_CONFIG_MACRO_DIR does something different (from autoconf info page): -- Macro: AC_CONFIG_MACRO_DIR (DIR) Specify DIR as the location of additional local Autoconf macros. So, first, check if aclocal.m4 is autogenerated by aclocal (it should tell that in the first or second line) Then check which libtool macro they use in configure.in (AC_PROG_LIBTOOL or AM_PROG_LIBTOOL) and grep for it in the sources. Post resulting file list (configure.in and aclocal.m4 are unimportant - if aclocal.m4 was autogenerated, if not we will have to see how was it generated). No, it definitely is not autogenerated: [~/bind-9.4.2]>cat aclocal.m4 sinclude(./libtool.m4)dnl [~/bind-9.4.2]>egrep -re A._PROG_LIBTOOL . ./lib/bind/configure.in: AM_PROG_LIBTOOL ./configure.in: AM_PROG_LIBTOOL ./libtool.m4:# serial 47 AC_PROG_LIBTOOL ./libtool.m4:# AC_PROG_LIBTOOL ./libtool.m4:AC_DEFUN([AC_PROG_LIBTOOL], ./libtool.m4:[AC_REQUIRE([_AC_PROG_LIBTOOL])dnl ./libtool.m4:])])# AC_PROG_LIBTOOL ./libtool.m4:# _AC_PROG_LIBTOOL ./libtool.m4:AC_DEFUN([_AC_PROG_LIBTOOL], ./libtool.m4:define([AC_PROG_LIBTOOL], []) ./libtool.m4:])# _AC_PROG_LIBTOOL ./libtool.m4:# In the future, this macro may have to be called after AC_PROG_LIBTOOL. ./libtool.m4:AC_DEFUN([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) ./contrib/idn/idnkit-1.0-src/aclocal.m4:# serial 40 AC_PROG_LIBTOOL ./contrib/idn/idnkit-1.0-src/aclocal.m4:AC_DEFUN(AC_PROG_LIBTOOL, ./contrib/idn/idnkit-1.0-src/aclocal.m4:# In the future, this macro may have to be called after AC_PROG_LIBTOOL. ./contrib/idn/idnkit-1.0-src/aclocal.m4:AC_DEFUN(AM_PROG_LIBTOOL, [indir([AC_PROG_LIBTOOL])])dnl ./contrib/idn/idnkit-1.0-src/configure.in:AM_PROG_LIBTOOL I do not have enough knowledge of autotools to judge, but is this what you were looking for? What I meant in comment #14 is that the output in said libtool log changes to m4/, likely becuase it installs the "local additional macros" there - you can see that for yourself (with only the patch): cat /tmp/portage/net-dns/bind-9.4.2/temp/libtoolize-15069.out ***** libtoolize ***** ***** libtoolize --copy --force --install libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./config.guess' libtoolize: copying file `./config.sub' libtoolize: copying file `./install-sh' libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: You should add the contents of `m4/libtool.m4' to `aclocal.m4'. libtoolize: copying file `m4/ltoptions.m4' libtoolize: You should add the contents of `m4/ltoptions.m4' to `aclocal.m4'. libtoolize: copying file `m4/ltsugar.m4' libtoolize: You should add the contents of `m4/ltsugar.m4' to `aclocal.m4'. libtoolize: copying file `m4/ltversion.m4' libtoolize: You should add the contents of `m4/ltversion.m4' to `aclocal.m4'. libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: You should add the contents of `m4/lt~obsolete.m4' to `aclocal.m4'. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT' In that case solution is trivial: rm ${S}/libtool.m4 ${S}/aclocal.m4 before eutoreconf line, your patch should not be necessary. I mean, of course, the line from original ebuild. Created attachment 152693 [details]
Fixed ebuild, the correct way.
The patch is no longer necessary with this.
Thanks Rafał, you are absolutely right. I thought I tried it, but must have toyed with too many things at the same time. (In reply to comment #17) > In that case solution is trivial: > rm ${S}/libtool.m4 ${S}/aclocal.m4 > before eutoreconf line, your patch should not be necessary. > Thanks to both of you, that did the trick. I just committed your fix to CVS. |