This problem appears to be present since 2008-07-23 at least. When trying to emerge from scratch, during the second `emerge -e system' step, during "Building (77 of 86) x11-libs/libXaw-1.0.4" I get this: checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip checking for correct ltmain.sh version... no configure: error: *** [Gentoo] sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.26, ltmain.sh = 1.5.22) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. make: *** [config.status] Error 1 * ERROR: x11-libs/libXaw-1.0.4 failed: * emake failed The output from `emerge --info' in the incomplete prefix tree is: Portage 2.2.00.11125-prefix (default-prefix/linux/x86, gcc-4.2.4, unavailable, 2.6.16.53-0.16-smp i686) ================================================================= System uname: Linux-2.6.16.53-0.16-smp-i686-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-SuSE-10-i586 Timestamp of tree: Thu, 24 Jul 2008 01:01:31 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18.50.0.7 sys-devel/gcc-config: 1.4.0-r04.5 sys-devel/libtool: 1.5.26 ACCEPT_KEYWORDS="~x86-linux" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/local/tmp/nightly/2008-07-24/usr/portage/distfiles" EPREFIX="/local/tmp/nightly/2008-07-24" FEATURES="collision-protect distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.gentoo.no/ http://mirror.qubenet.net/mirror/gentoo/ http://mirror.muntinternet.net/pub/gentoo/ http://ftp.linux.ee/pub/gentoo/distfiles/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="en_US" LDFLAGS="" MAKEOPTS="-j2" PKGDIR="/local/tmp/nightly/2008-07-24/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/local/scratch" PORTDIR="/local/tmp/nightly/2008-07-24/usr/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="X cracklib iconv midi mudflap ncurses nls openmp prefix readline ssl unicode x86 zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Fixed, thanks for reporting, related to the eclass change that haubi did earlier this week. Must have slipped through.
Ohw, thanks for pointing out! For performance reasons, in x-modular.eclass I do the eautoreconf independent of $SNAPSHOT for aix and interix only, where it is necessary always. Should we do eautoreconf for all platforms always in prefix, or should we detect the need for eautoreconf by searching the patches applied? Or better have some additional variable like X_MODULAR_DO_EAUTORECONF=yes to be set in the ebuild? Because for libXaw eautoreconf is done twice now on aix and interix, which isn't too good either...
Unless there is a good reason not to do this, I suggest making the eautoreconf function touching a .eautoreconfed file, such that another eautoreconf silently returns immediately.
Shouldn't this be done upstream too? Currently only elibtoolize does so, which is (part of) the problem.
Preferably, yes. Need to craft a patch and get permission from the right persons before applying to gentoo-x86 though. (Discussion first might help, since I'm not sure my idea is a good solution at all.)
(In reply to comment #5) > Preferably, yes. Need to craft a patch and get permission from the right > persons before applying to gentoo-x86 though. (Discussion first might help, > since I'm not sure my idea is a good solution at all.) > I don't think anyone would argue about it. There is no reason that eautoreconf has to be ran twice, just call it in the proper place one time. I see two causes that would make eautoreconf run twice: 1) a person types it twice (unlikely) 2) it is hidden in an eclass that someone doesn't know about and s/he puts it in the ebuild explicitly. With my patch, you can easily override the touch file by simply removing it and running eautoreconf again in the ebuild. Should be a non-discussion point ;)
(In reply to comment #6) > With my patch, Oops. Here it is: %% svn diff Index: autotools.eclass =================================================================== --- autotools.eclass (revision 28742) +++ autotools.eclass (working copy) @@ -81,6 +81,9 @@ # Also should handle additional directories specified by AC_CONFIG_SUBDIRS. eautoreconf() { local pwd=$(pwd) x auxdir + + [[ -f .eautoreconfd ]] && einfo "eautoreconf already ran, skipping" && return 0 + touch .eautoreconfd if [[ -z ${AT_NO_RECURSIVE} ]]; then # Take care of subdirs Tested by putting eautoreconf in the ebuild twice. Works great. Please review and I will commit to prefix and bug upstream about it.
fine with me.
Committed to gentoo-x86 with permission from robbat2. 14:06 <@darksiide> robbat2: hi, in autotools.eclase there is a check to make sure the elibtoolize doesn't run more than once. I would like you to consider this for eautoreconf as well. 14:06 <@robbat2> darksiide, pastebin a patch? 14:06 <@darksiide> robbat2: here is my suggested patch: https://bugs.gentoo.org/show_bug.cgi?id=232820#c7 14:06 <@robbat2> cla, pong 14:07 <@robbat2> darksiide, +1 to commit 14:08 <@darksiide> robbat2: thx, i'll do it now then
Oh boy, seems like I might have made a mistake. 15:30 <+drac> darksiide: flameeyes said he explicitely not added the .eautoreconfed on purpose.. 15:30 <+drac> darksiide: and that it breaks the eclass and you get to keep the pieces... might want to talk to him ; I reverted my commit for now and am talking to flameeyes via email to see if there is a resolution.
Alrighty, sorry all for morphing this bug into a WONTFIX. my apologies there. The bottom line is that my patch is too hacky for gentoo-x86's use and shouldn't be there. I copied elibtoolize's method of the dot-file check but that doesn't really apply here because eautoreconf may or may not be recursive like elibtoolize is. (bad point #1). Also, something that I did not think of thoroughly is if the eclass is written poorly. I was basing my testing off of x-modular.eclass, which Donnie did a very nice job on. However, something like this would fail: eclass_src_unpack() { dosomecrazystuff eautoreconf } src_unpack() { eclass_src_unpack epatch $SOMEPATCH # changes autotools eautoreconf } (or it would cause a maintainer-mode driven rebuild anyway which defeats the point of my patch, or skip the patch, both bad) Conclusion: it is better to run autotools twice then fail and shoot ourselves in the foot. =/
In prefix, elibtoolize now understands "--force", used by eautoreconf: http://overlays.gentoo.org/proj/alt/changeset/29175 Now this comment in eautoreconf() is correct: # Call it here to prevent failures due to elibtoolize called _before_ # eautoreconf. Doing eautoreconf more than once doesn't hurt now (except for buildtime). Should this go to gentoo-x86 too?
my opinion here is that the eclass/ebuild is broken if eautoreconf is invoked multiple times. it's a waste of time on the end system. so fix the packages rather than adding this check which can easily cause problems as already documented in previous comments.
Agreed, but unfortunately these broken eclasses/ebuilds already exist - and for some eclass constructs it doesn't seem too trivial to fix. So what about this? 1) Add some QA-warning when eautoreconf is called more than once. 2) but still do like 'elibtoolize --force', maybe with FEATURES=-stricter only. Maybe this could be done in elibtoolize only - when .elibtoolized already exists.
adding automatic detection of duplicate autotool calls makes sense, and for now, we can QA warn. that'll generate bugs and/or fixes. once everything is fixed, we change it to a die. as for the rest, i still dont think adding workarounds makes sense. especially when tied to FEATURES such as stricter.
From a pure technical POV, eautoreconf can be done as much often as one likes. Although there should be a QA-warning, it should 'just work' IMO - unrelated to FEATURES indeed. Btw, haven't seen any problems with 'elibtoolize --force' called by eautoreconf in Prefix since.
Ok, so this looks like there are two issues: 1) creating code to warn in case eautoreconf or elibtoolize is ran for the second time (although flameeyes says that is intended in some cases) 2) the ability to force elibtoolize to run for the second time (--force flag) which aparently is necessary to quickly work around broken situations. @haubi, do we still need the --force, or can we do without these days too?
Seems libXaw doesn't need the darwin patch any more which (iirc) initially triggered this issue, although the old ebuilds still do the additional eautoreconf. Anyway, IMO upcoming xorg-2.eclass should address this issue and provide some (simple) mechanism to allow the ebuild to force eautoreconf: http://archives.gentoo.org/gentoo-dev/msg_b30bec98c92e3c9485f449094e91eea4.xml
Now, I've a package here in some local overlay doing this in the ebuild: *) run a generator to create configure.ac and Makefile.am scanning the sources *) eautoreconf *) econf *) emake in-package-code-generator *) run in-package-code-generator to get some more sources *) emake distclean *) run generator to create configure.ac and Makefile.am scanning the sources, now containing generated source files *) eautoreconf *) econf *) emake While the need to run the in-package-code-generator is arguable for the released package, it is required in a live-vcs ebuild. So it really should "just work" to run eautoreconf multiple times IMO.
hmm, i've noticed pygobject has the same issue: - pygobject's src_prepare executes gnome2_src_prepare which runs elibtoolize - pygobject runs eautoreconf - autotools are rebuilt and blow away the elibtoolize work from earlier - elibtoolize is skipped from eautoreconf - end result is local libtool is not patched
i think from the prefix side, this should be all set. for ebuilds which now get a QA warning, those will get new bugs. http://sources.gentoo.org/eclass/autotools.eclass?r1=1.109&r2=1.110 http://sources.gentoo.org/eclass/libtool.eclass?r1=1.94&r2=1.95
