m4 1.4ppre2 is mayor borked and need to be changed as soon as possible. I noticed this problem while doing my regular PHP HEAD builds for QA purpose, and we changed to require libtool 1.4.3 to solve some Solaris build problems 2 days ago. So I unmasked libtool in my package.mask and upgraded to it. First of all, when I built configure script we got alot of warnings about bugs in autoconf, we use 2.13. After some investigation from _sniper_ (Jani) he found out that the m4 version is very broken, and that autoconf 2.13 needed to be recompiled too. So he downloaded the orginal versions from gnu.org which solved the problems. Right now I'm using: GNU m4 1.4 Autoconf version 2.13 without any patches applied from portage. Have installed some other stuff from portage without problems with the orginal (known to work) versions of both tools. Also, autoconf 2.57 seems to be installed by default on all machines, so libtool 1.4.3 can be unmasked if the comment is true. However, it should NOT be the default, 2.13 should continue to be default since it is the only version that really works. 16:08 <@_sniper_> coredumb: Yeah, autoconf/m4 from Gentoo suck ass. Reproducible: Always Steps to Reproduce: Portage 2.0.46-r12 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r3) ================================================================= System uname: 2.4.20-gentoo-r1 i686 Celeron (Mendocino) GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/kde/3/share/config /opt/glftpd/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 3dnow apm libg++ mikmod arts bonobo svga ggi tcltk guile cdr alsa plib avi berkdb gtk gnome lame ipv6 java libwww php samba nls zlib perl python encode ncurses xmms flash crypt ldap pdflib oggvorbis truetype mpeg qtmt gtkhtml dvd gtk2 tetex qt kde ssl imap mbox maildir mmx jpeg png tiff gif motif mozilla readline gpm divx opengl sdl mysql gd oss xml2 cups pam imlib spell slang quicktime gdbm xv cracklib db fam innodb tcpd esd xpm X snmp" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -mmmx -O3 -pipe" CXXFLAGS="-march=pentium2 -mmmx -O3 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j3" AUTOCLEAN="no" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Here are the warnings we get during buildconf: using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ACVERSION ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX configure then fails with: ./configure: line 17247: syntax error near unexpected token `(' ./configure: line 17247: ` echo $ac_n "(cached) $ac_c" 1>&6'
*** Bug 15452 has been marked as a duplicate of this bug. ***
I have done some (maybe limited) investigation of what packages which won't install with libtool 1.4.3. Here is the small list: db 3.2.9-r1 glib 1.2.10-r5 alsa-lib 0.9.0_rc7 There is however an easy way to get around that, SED="/bin/sed" emerge .... or simply specifying SED="/bin/sed" ./configure .... in the ebuilds that won't compile with libtool 1.4.3. Maybe this should be a separate bugreport?
Ok, assuming you are right, I went back to m4-1.4o: ---------------------------------------------------------------- azarah@nosferatu php $ cp -a php5/ test azarah@nosferatu php $ cd test/ azarah@nosferatu test $ ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_ACVERSION ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX configure.in:562: AC_TRY_COMPILE was called before AC_AIX configure.in:562: AC_TRY_RUN was called before AC_AIX azarah@nosferatu test $ ---------------------------------------------------------------- Which have the same result. Ok, maybe you meant the original 1.4 release: ---------------------------------------------------------------- azarah@nosferatu test $ ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in azarah@nosferatu test $ ---------------------------------------------------------------- Which works fine, great stuff. I have however been under the impression that the errors with m4-1.4[op] was related to libtool-1.4.[23] needing autoconf-2.5x rather than 2.13 (which you say is broken, but many projects does use with success), thus lets try again: ---------------------------------------------------------------- azarah@nosferatu test $ cd ..; rm -rf test; cp -a php5/ test; cd test azarah@nosferatu test $ WANT_AUTOCONF_2_5=1 ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.57 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. buildconf: automake version 1.4-p5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. azarah@nosferatu test $ ---------------------------------------------------------------- Which works fine, except for the warning about changed policy in auxiliary files, but are harmless. Thus, do we conclude that: 1) m4-1.4[op] are really broken ? 2) For libtool-1.4.[23] you need autoconf-2.5, and m4-1.4 (not 1.4[op]) are broken and just do not parse things properly to detect the errors. Guess it will be best to consult with somebody involved with autoconf/m4.
I am using the orginal 1.4 version of m4. I have compiled almost a whole system now with libtool 1.4.3 without any problems, except that for some packages you need to pass SED="/bin/sed" before emerge (or fix the ebuild), otherwise libtool 1.4.3 won't find your sed for some reason. One thing I should mention is that you should recompile your autoconf after changing m4 version. That is why I also said that autoconf 2.13 is borked, which might only be a side effect of broken m4. However, after the change of m4 version and recompile of autoconf 2.13, everything works fine again. Also, I made my own m4 ebuild for my system when I remade it and as I said before, some packages doesn't compile with libtool 1.4.3, but it's not something hard (for me at least) to fix. Just use SED="/bin/sed" emerge package. Except for that it works fine this far.
Check the changelog of sed .... its because autoconf-2.13 cannot handle some of the macro's of libtool-1.4.[23], and thus it better to use autoconf-2.5x with them. I am however not going to argue about this .. I will contact the m4/autoconf authors, and get a opinion there. MDK use m4-1.4ppre2, Redhat use a 1.4.1_pre that they pulled out somewhere. I cannot think that they all would use those if stock 1.4 was working 100% as it should ... Problem is that as a source distro, most things compile fine, even CVS php ... just maybe not with autoconf-2.13. This goes for libtool-1.4.3. I will not just change them because of one package, because the rest (and yes, I have done some testing in the past) will have to be synced as well, wich will be no minor task. I will rather then get libtool to be dual version'd like autoconf and automake. I will post as soon as I know more.
Woops, slip of the finger.
Ok, added a patch to libtool-1.4.3-r1 to fix the SED issue. Also added m4-1.4 to portage. From what I can see from the 1.4.1 from Redhat, is that it is much closer to 1.4 straight, than 1.4[op]. Debian also still use 1.4 straight in even their unstable branch, and after some extensive testing over here (and no reply from the m4/autoconf/whoever except that I should not mail them direct) it seems fine.
Added m4-1.4 and masked the rest. Added new revs of autoconf that depend on 1.4 only.
http://mail.gnu.org/archive/html/libtool/2001-09/msg00064.html Explains the reason why this is exposed in >=libtool-1.4.2. It is a bug in libtool, not m4p. Fixing this in libtool should resolve the problem. That version of m4 is *ancient* and many annoying bugs were fixed since then in the beta m4's. I highly suggest we patch libtool and use the newer m4's. Since I've had a lot of experience with libtool on the Cygwin project, I'll work on it if no one else will.
Maybe. But its got the latest Debian patches. Also, pretty much the same as Redhat use. And no m4 beta has been out in a long time.
I don't think the debian patches can address all the issues I recall that m4-1.4 had. The older m4 hangs when used to build scripts in some cvs trees, I can't remeber which ones, but I do know that was the case previously. Debian is also know for being ultra-conservative, so it doesn't suprise me that they are still using an ancient m4. BTW, the m4 lists are a blackhole, that is noone is checking them. I've gone ahead and directly emailed Gary the problem and asked him if he had any better solutions developed in the mean time. As for a newer beta, if you check the savannah cvs repo, m4 development has been chugging along. I don't know why he hasn't released a newer bianary, I guess you'd have to ask him... I've also downgraded this to major, since technically libtool-1.4.3 is masked and even if it wasn't, this bug hasn't surfaced in regular ebuilds. I should know, I've been using libtool-1.4.3 for months now.
Open A new bug if m4-1.4 have issues. The original issue is solved.
