Hi, I really don't know if this is a bug or if I messed up something. Well, anyway... The configure script starts normally, but then: ################################################ [..] creating metamail/config.h cd . && aclocal -I config cd . && automake --foreign Makefile cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile cd . && autoconf FATAL ERROR: Autoconf version 2.50 or higher is required for this script make: *** [configure] Fehler 2 !!! ERROR: net-mail/metamail-2.7.45 failed. !!! Function src_compile, Line 418, Exitcode 2 !!! emake failed ################################################ autoconf-2.59 is definetly installed. I also tried following: ################################################ WANT_AUTOCONF=2.5 emerge metamail [..] creating metamail/config.h cd . && aclocal -I config cd . && automake --foreign Makefile cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile cd . && autoconf configure.in:350: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Fehler 1 !!! ERROR: net-mail/metamail-2.7.45 failed. !!! Function src_compile, Line 418, Exitcode 2 !!! emake failed ################################################### My "emerge info": ################################################### Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040207-r0, 2.6.2-rc2) ================================================================= System uname: 2.6.2-rc2 i686 AMD Athlon(tm) XP 1600+ Gentoo Base System version 1.4.3.13 distcc[22145] (dcc_trace_version) distcc 2.12.1 i686-pc-linux-gnu; built Jan 21 2004 21:48:42 [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse -ffast-math -fomit-frame-pointer -O3 -pipe -funroll-loops -falign-functions=4" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /opt/glftpd/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse -ffast-math -fomit-frame-pointer -O3 -pipe -funroll-loops -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache noclean sandbox userpriv usersandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa apm arts avi berkdb cdr crypt directfb encode esd fbcon foomaticdb gdbm gif gnome gpm gtk gtk2 guile imlib java jpeg kde libg++ libwww mad mikmod mmx motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby sdl slang spell sse ssl tcltk tcpd tetex truetype x86 xml2 xmms xosd xv zlib" ####################################################### If you need more info, let me know. Thanks in advance. Arash Reproducible: Always Steps to Reproduce:
Sorry for the de_DE@euro, forgot to switch to C.
can you try with libtool-1.5.2-r3 ?
I did. No changes, the error still occurs.
I've got the same problem. Seems strange that the ebuild is marked stable when it doesn't even go through the autoconf-part. Or are we the only ones having this problem?
not really ... just because you're using an unstable set of autotools that cause stable packages to fail doesnt mean it's the stable packages' fault :P
Well, this time it is since the manual page for autoconf (both 2.58 and 2.59) states that LIBOBJS in an forbidden token, which is what it complains about when trying to emerge the package with an autoconf-version of 2.5 or higher. And since the building of metamail requires >autoconf-2.5 it's pretty obvious that metamail is at fault even though it's an upstream issue.
Autoconf-2.57-r1 reproduces a different error, but fail to compile too. It complain about autoconf version, and it seems completely ignore the "WANT_AUTOCONF=2.5" flag. Autoconf-2.58 and autoconf-2.59 does the same errors as decribed by Arash. Let me known if you need more info.
very strange. ran FEATURES="keeptemp keepwork" WANT_AUTOCONF="2.5" emerge metamail, and it failed. Ran again, and it succeeded. More research is in order...
Had same problem: "FATAL ERROR: Autoconf version 2.50 or higher is required for this script" Edited ebuild to read "make WANT_AUTOCONF=2.5 DESTDIR=${D} install || die" and got same error, reverted ebuild to original tried "WANT_AUTOCONF=2.5 emerge metamail" and got the "error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS'" tried "FEATURES="keeptemp keepwork" WANT_AUTOCONF="2.5" emerge metamail" and got success on first attempt
I ran "FEATURES="keeptemp keepwork" WANT_AUTOCONF="2.5" emerge metamail" and it failed with the "do not use LIBOBJS directly"... Ran it again and it emerged ok. Wierd.
I confirm that comment#10 is a good workaround; worked for me first attempt. My environment is new system installed from scratch ~x86, nptl, 2.6.3_rc2, 2.6 headers, and udev. emerge running in a terminal (aterm) under X (su -).
comment 10 worked fine for me too, using sys-devel/autoconf-2.59-r1.
comment 10 doesn't work for me. And using autoconf-2.59-r1 produces the error message I described when using "WANT_AUTOCONF=2.5 emerge metamail". Seems that autoconf-2.59-r1 has fixed the wrapper as described in the autoconf changelog, but there problem remains: configure.in:350: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 !!! ERROR: net-mail/metamail-2.7.45 failed. !!! Function src_compile, Line 418, Exitcode 2 !!! emake failed
I made a patch to configure.in which removes the offending code that autoconf complains about. This because of a section in autoconf's info about "AC_LIBOBJ vs LIBOBJS" (easy to find) which said that the code that it complains about is no longer neccesary in newer releases of autoconf. But when emerging with the patch it gets stuck somewhere running sed at 100% cpu. The last text displayed when doing it this way is the following: ... checking for putenv... yes configure: creating ./config.status cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status config.status: creating Makefile As the sed-portion of config.status is rather extensive I haven't been able to verify where sed gets stuck so I'm at a loss... Maybe some sed-guru can figure it out.
thanks a lot, comment #10 works form me in the second try.
For me, commenting out the offending lines (349-351) in configure.in worked without getting the said infinite loop from sed.
Comment 10 worked for me. :D
Comment 10 worked for me too, but I'm surprised this hasn't been fixed yet since it's in stable. Wonder if it's just certain people having trouble with it or whether it's a general thing.
I encountered the same problem, and comment #10 worked for me.
Similar problem for me on Sparc, but the 'fix' in comment #10 worked for me too. Raising severity -- there is only one version of metamail in the tree, and a fix should be included soon.
Any update on this?
This does not occur on x86 and was verified on PPC by liquidx, I would be happy to assist with ppc testing or whatever just ping me in #gentoo-dev, however i am on vacation currently and my internet access is spotty, but I'll be back by Thursday.
Hmmm the first reporter got this on x86...
this bug is almost two months old, is anyone alive? I can confirm this IS happening on x86, whomever said it wasn't must be doing something different.
I just tried with autoconf-2.59-r3 and it worked for me -- I've actually never been able to repro this bug. Would you believe I wish I could though. what versions of autoconf, libtool and automake are y'all running? (where y'all == peeps experiencing this bug)
[ebuild R ] sys-devel/autoconf-2.58-r1 0 kB [ebuild R ] sys-devel/libtool-1.4.3-r4 0 kB [ebuild R ] sys-devel/automake-1.7.7 0 kB steps to reproduce: 1) emerge metamail 2) wait a minute 3) cry. actual output: [snip] creating bin/Makefile creating metamail/config.h cd . && aclocal -I config cd . && automake --foreign Makefile cd . \ && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile cd . && autoconf configure.in:350: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 !!! ERROR: net-mail/metamail-2.7.45 failed. !!! Function src_compile, Line 418, Exitcode 2 !!! emake failed expected output: >>> net-mail/metamail-2.7.45 merged.
Calculating dependencies ...done! [ebuild R ] sys-devel/autoconf-2.59-r3 [ebuild R ] sys-devel/automake-1.8.3 [ebuild R ] sys-devel/libtool-1.5.2-r5 would you be willing to try those versions?
Still nothing...
configure.in:350: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
&& CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status creating Makefile cd . && autoconf configure.in:350: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 !!! ERROR: net-mail/metamail-2.7.45 failed. !!! Function src_compile, Line 418, Exitcode 2 !!! emake failed still get this error, have latest ~x86 libtool, autoconf, automake, used this command FEATURES="keeptemp keework" WANT_AUTOCONF="2.5" emerge metamail still failes
eh ran #10 , and third times a charm! :(
Still broken. The keepwork/temp worked for me. [ebuild N ] sys-devel/libtool-1.5.2-r5 [ebuild N ] sys-devel/autoconf-2.59-r3 [ebuild N ] sys-devel/automake-1.8.3 Please fix =)
Please do not remove people from the CC without asking them first. There are reasons for some of us wanting to be on the CC.
Thanks for removing me from the CC.
What's with the CC removal?
This bug is still alive and well for metamail-2.7.45, but the comment #10 workaround got me by the problem.
Comment #10 worked also for me :)
Created attachment 30055 [details, diff] Update configure.in as recommended in autoconf manual Yeah #10 worked for me too. Looking at the autoconf manual as suggested in the error output, it suggests a replacement for the line used in metamail's configure.in. If you replace line 350: LTLIBOBJS=`echo X"$LIBOBJS"|[$Xsed -e "s,\.[^.]* ,.lo ,g;s,\.[^.]*$,.lo,"]` with: LTLIBOBJS=`echo X"$LIB@&t@OBJS" | $Xsed -e 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'` ./configure will run without complaint. Using: * sys-devel/autoconf Latest version available: 2.58-r1 Latest version installed: 2.58-r1 /usr/portage/distfiles/mm2.7.tar.Z /usr/portage/distfiles/metamail_2.7-45.diff.gz diff on configure.in attached.
Comment 10 worked for me as well.
Comment 10 worked for me as well :)
I didn't see comment #10 when I started, because I googled the error first and found this in the home page of a program called Trickle, which is similar to what comment #10 did and worked: URL:<"http://monkey.org/~marius/trickle/">: quirks * note that on certain systems you may get the following error on "make": configure.in:220: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS' If this token and others are legitimate, please use m4_pattern_allo See the Autoconf documentation. make: *** [configure] Error 1 this is easily circumvented by running make again. ^^^^^^^^^^^^^^^^^^ What I did was after the failure, do ebuild $(equery which metamail) compile install qmerge clean which worked. My system is mostly x86; only the kernel and headers in the base system are above that. There was only one version of metamail in portage, so obviously trying other versions of metamail in portage was a noop. Re-emerging autoconf didn't fix the problem. There is no package named autotools. autoconf strikes again. autoconf has been starting to cause more problems than it solves in recent years. This is not Gentoo's fault. However, I admit perhaps we don't know how much our dependency on autoconf has grown (e.g., wonderful systems like Gentoo which might have very different layouts from system to system) -- sort of like an addiction. What the C/Unix/Linux systems need is an effective project to replace autoconf with something easier to program and more stable. If autoconf were easier to program, we could fix it more often. I've tried many times to understand autoconf, and it is a complete mess. Using scripts and macros is a really bad idea; autoconf should be written in C. The management of autoconf would then be that of maintaining and distributing C code, which IMO would be a lot easier than maintaining scripts and macros and properly integrating and distributing the dependencies. (The C code would probably be a very obvious, straightforward, and simple implementation of a script system, but one which doesn't have horrible, messy, and impossible to understand syntax like autoconf scripts currently do. No function would be implemented in inferior scripts any more; parsing header files and looking at library objects would be done either directly in C or directly with program invocations from C. There are probably other autoconf reimplementation approaches to this problem which would be better than the current situation.) autoconf is so hard to program that I can't tell whether or not the current bug is autoconf, metamail, or some other program's fault. (I never trust it until it works, and even then not much.)
*** Bug 48738 has been marked as a duplicate of this bug. ***
*** Bug 49533 has been marked as a duplicate of this bug. ***
Maybe I'm oversimplifying things, but an "autoreconf" seems to fix the problem and avoids the sed issue. Is there some reason I shouldn't commit an update and close this bug? Feel free to re-open this if I'm missing something crucial...