Summary: | sys-devel/autogen installs colliding m4 macros which break random packages | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Adrian.Bassett, alexxy, bircoph, bkorb, bugs+gentoo, damien.thebault, ed, eva, flameeyes, galtgendo, gentoo, gentoo, h.v.bruinehsen, ishkulov, jackdachef, jarausch, julien.enche, kdart, kentnl, mbakhoff, mkyral, nobodydead, ooblick, pkugrinas, polynomial-c, python, solstag, tdalman, tomka, willard.dawson, zeekec, zzam |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 321905 | ||
Attachments: |
/var/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/config.log
configure /var/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/configure autogen-extensions.patch |
Description
Juergen Rose
2010-11-29 00:07:33 UTC
Created attachment 255777 [details]
/var/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/config.log
(In reply to comment #0) > 'emerge python' fails with: > ... > > checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed > checking for --with-cxx-main=<compiler>... no > configure: error: cannot run /bin/sh ./config.sub Same here. Attach 'configure' script from after src_prepare(). *** Bug 347205 has been marked as a duplicate of this bug. *** Created attachment 255881 [details]
configure
My configure script.
Note: I cannot find a config.guess or config.sub in the build directory
find /gentoo/tmp/portage/dev-lang/python-2.7.1/ -name config.\*
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/PC/os2vacpp/config.c
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/PC/os2emx/config.c
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/PC/config.c
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/RISCOS/Modules/config.c
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/Modules/config.c.in
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/config.log
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/Lib/logging/config.py
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/Lib/distutils/command/config.py
/gentoo/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/Lib/distutils/config.py
The cause of the failure has something to do with autoheader which is run during the autoreconf in src_prepare(). If you modify the package yourself to remove the eautoreconf line, it works fine (well, it builds and all that but if there were any mods to the configure script they wouldn't have been applied successfully). This seems to have affected all the builds from python-2.7.1_pre20101030 onwards. Error message is as follows: autoheader-2.68: warning: missing template: _ALL_SOURCE autoheader-2.68: Use AC_DEFINE([_ALL_SOURCE], [], [Description]) autoheader-2.68: warning: missing template: _POSIX_PTHREAD_SEMANTICS autoheader-2.68: warning: missing template: _TANDEM_SOURCE Created attachment 255925 [details]
/var/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1/configure
Also still my configure
Exactly same problem here. Do we need more configure scripts? )ˇ( Confirming this bug, exactly the same here. *** Bug 347373 has been marked as a duplicate of this bug. *** After generating a clean install on a chroot with only automake-1.11.1 installed python 2.7.1 builds properly. After doing a world rebuild automake 1.8.5-r4 was pulled in .. this results in python-2.7.1 not building .. a non-refreshed terminal with just automake-1.11.1 in it's environment .. built python-2.7.1 just fine. someone want to fix this now? oops an error .. simply adding automake-1.8.5-r4 did not prevent from building python-2.7.1 to build .. so something else is going on as well? .. I had too many terminal open so The previous comment was in error .. sorry $ ebuild /usr/portage/dev-lang/python/python-2.7.1 prepare $ cd /var/tmp/portage/dev-lang/python-2.7.1/work/Python-2.7.1 $ automake --add-missing --copy $ ebuld /usr/portage/dev-lang/python/python-2.7.1 configure Then it compiles. Could this be in some way related to the recently discussed automake/libtool problem ? If so, perhaps Removing sys-devel/autogen fixes the problem for me. It seems to be a problem with /usr/share/aclocal/extensions.m4 (included in autogen). After removing the package I could emerge python normally. *** Bug 347667 has been marked as a duplicate of this bug. *** (In reply to comment #15) > Removing sys-devel/autogen fixes the problem for me. It seems to be a problem > with /usr/share/aclocal/extensions.m4 (included in autogen). > > After removing the package I could emerge python normally. > Works for me, too. Interesting, removing autogen fixes the ebuild for me to. I also happen to have a subversion workspace of Python 2.7 and it builds fine even with autogen installed. I did have to remove the version check in configure.in and re-run autoconf, just like the ebuild does. Seems to point to autogen or wrapper script. confirming that removal of autogen fixes the issue for me as well.. for me .. anjuta pulls in autogen (In reply to comment #19) > confirming that removal of autogen fixes the issue for me as well.. > > for me .. anjuta pulls in autogen > For me: net-analyzer/tcpreplay-3.4.4-r1 (>=sys-devel/autogen-5.9.8) sys-devel/gcc-4.4.5 (test ? >=sys-devel/autogen-5.5.4) sys-devel/gcc-4.5.1-r1 (test ? >=sys-devel/autogen-5.5.4) However, "temporarily" uninstalling autogen allows for python-2.7.1 to merge. So, no harm, though it's a hoop that ought not be required. Well, the file mentioned in comment 15 overrides a standard autoconf macro (it actually explicitly tells so) - probably in a way that's incompatible with recent autoconf. *** Bug 347828 has been marked as a duplicate of this bug. *** Problem appears to be that AC_USE_SYSTEM_EXTENSIONS from autogen has AC_REQUIRE([AC_CANONICAL_HOST]) which pulls in AC_CANONICAL_HOST, which pulls in AC_CANONICAL_BUILD, which adds the config.sub requirement. AC_CANONICAL_HOST appears to be required to define host_os for this stanza: dnl HP-UX 11.11 defines mbstate_t only if _XOPEN_SOURCE is defined to 500, dnl regardless of whether the flags -Ae or _D_HPUX_SOURCE=1 are already dnl provided. case "$host_os" in hpux*) AC_DEFINE([_XOPEN_SOURCE], [500], [Define to 500 only on HP-UX.]) ;; esac The simplest fix I can think of is to change the AC_REQUIRE to an AC_BEFORE: AC_BEFORE([AC_CANONICAL_HOST], [$0])dnl as anyone who's interested in cross-compiling to run on HP-UX is likely to be calling AC_CANONICAL_HOST anyway. I'll provide a patch to autogen. Created attachment 256423 [details]
autogen-extensions.patch
Use AC_REQUIRE in autogen extensions.m4
I'd say what's described in comment 23 is the opposite of a solution. The problem seems to lie in the override requiring AC_CANONICAL_HOST in the first lace, as the upstream (that is autoconf) version no longer requires it. If possible, perhaps removing the overriding macro from extensions.m4 would be a step in right direction. My point is: it's one thing to override a common macro in your own configure script, it's another to install such override in /usr/share/aclocal. Since AC_USE_SYSTEM_EXTENSIONS is provided by autoconf (at least with autoconf > 2.62), the definition provided by autogen should really be wrapped in a m4_ifndef. Probably need to wrap gl_USE_SYSTEM_EXTENSIONS as well. (In reply to comment #24) > Created an attachment (id=256423) [details] > autogen-extensions.patch > > Use AC_REQUIRE in autogen extensions.m4 This patch brokes autogen-5.11.1 compilation with USE=doc: configure.ac:137: the top level configure.ac:137: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2662: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2679: AC_LINK_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... config/ag_macros.m4:356: AG_WITHLIB_XML2 is expanded from... config/ag_macros.m4:671: INVOKE_AG_MACROS is expanded from... configure.ac:137: the top level doc/Makefile.am: `doc/autogen.texi' missing @setfilename make: *** [Makefile.in] Error 1 emake failed It is not possible to remove autogen on my system in the sane way: $ qdepends -Q autogen net-analyzer/tcpreplay-3.4.4-r1 i cant see any reason for autogen to even install these random .m4 files that are not produced by autogen. these files are fine as they're "autogen" namespaced and such: /usr/share/autogen/autoopts.m4 /usr/share/aclocal/ag_macros.m4 /usr/share/aclocal/autoopts.m4 these dont seem terribly useful, but maybe Bruce knows more: /usr/share/aclocal/liboptschk.m4 /usr/share/aclocal/snprintfv.m4 these files make no sense ... they're coming from gnulib (which should never be installed) or libopts (which is a package all by itself) or colliding with standard autoconf macros: /usr/share/aclocal/unlocked-io.m4 /usr/share/aclocal/extensions.m4 /usr/share/aclocal/libopts.m4 liboptschk.m4 is for other packages to validate the libopts installation. unlocked-io.m4/extensions.m4? I need to use them but I don't think I need to install 'em. I'll have to figure out what I really needed to do. By the way, I am in the process of making the posix modules from gnulib into a single project: libposix. Once established, I'd fix my configure script to look for it and just plain quit if it isn't present and have next-to-nothing to do if it is present. Since your build constructs seem to turn up more conflicts than just about any other, your feedback would be appreciated. There has been some discussion about it on the gnulib email list. Thank you. Regards, Bruce *** Bug 348040 has been marked as a duplicate of this bug. *** I am running down the "how to not install .m4 files" information: http://www.mail-archive.com/autoconf@gnu.org/msg20360.html because I really don't want to install anything but the one I put into the share/autogen directory. OK, you will like 5.11.4 a lot better. $ (\cd $HOME/tmp/_I;find * -type f|fgrep m4) usr/local/share/autogen/liboptschk.m4 usr/local/share/autogen/autoopts.m4 usr/local/share/aclocal/autoopts.m4 CF: Comment #29: > these dont seem terribly useful, but maybe Bruce knows more: > /usr/share/aclocal/liboptschk.m4 That is a macro that autoopts clients may wish to use as in: ag_FIND_LIBOPTS which is a wrapper to use "autoopts-config" for setting some values. It looks like it was written long ago, because the variables set I now know to be in the package builder's domain: f=`autoopts-config cflags` 2>/dev/null if test X"${f}" = X then : else AC_DEFINE([HAVE_LIBOPTS],[1],[define if we can find libopts]) CFLAGS="${CFLAGS} ${f}" f=`autoopts-config ldflags` 2>/dev/null test X"${f}" = X && f=`libopts-config ldflags` 2>/dev/null LIBS="${LIBS} ${f}" I'll fix it for final 5.11.4 release. (In reply to comment #33) > I am running down the "how to not install .m4 files" information: > http://www.mail-archive.com/autoconf@gnu.org/msg20360.html > because I really don't want to install anything but the one > I put into the share/autogen directory. > I'm not sure if I understand you, but major part of your problem seems to come from putting all of the macros into aclocal_DATA, instead of EXTRA_DIST, in top level Makefile.am - *_DATA files get installed, EXTRA_DIST not. P.S. in the interim: http://autogen.sourceforge.net/data/autogen-5.11.4pre7.tar.bz2 it would be nice to know that this does, indeed, solve this issue. seems the autoopts.m4 file is installed twice (once into aclocal/ and once into autogen/), but the rest looks ok (no more .m4 installed). the autogen-5.11.3 ebuild now punts the files: /usr/share/aclocal/{liboptschk,snprintfv,unlocked-io,extensions,libopts}.m4 *** Bug 348160 has been marked as a duplicate of this bug. *** *** Bug 348443 has been marked as a duplicate of this bug. *** *** Bug 355733 has been marked as a duplicate of this bug. *** *** Bug 368357 has been marked as a duplicate of this bug. *** |