Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 2929 - our m4 breaks latest autoconf-2.53 at emerge
Summary: our m4 breaks latest autoconf-2.53 at emerge
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GCC Porting (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
: 2979 3018 5947 (view as bug list)
Depends on:
Reported: 2002-05-22 15:39 UTC by Matthew Kennedy (RETIRED)
Modified: 2003-02-04 19:42 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Kennedy (RETIRED) gentoo-dev 2002-05-22 15:39:34 UTC
$ emerge autoconf
	--language=m4sugar			\
	--freeze			\
	--include=./..		\
	--include=..			\
	--language=m4sh			\
	--freeze			\
	--include=./..		\
	--include=..			\
autom4te: need GNU m4 1.4 or later: /usr/bin/m4
make[2]: *** [m4sugar.m4f] Error 1
make[2]: *** Waiting for unfinished jobs....

# m4 --version
GNU m4 1.4ppre2 (options: modules)

1.4ppre2 is a later release than 1.4. i bet the logic in autoconf which greps
the version from m4 is tripping on the "ppre2".
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-22 16:30:27 UTC
Weird thing is .. it works fine here, bleh.
Comment 2 Gerard Saraber 2002-05-22 22:05:10 UTC
I'm having the same problem ... only it gets better :-)
when I use emerge autoconf i get the error as reported, but when I cd to the tmp
dir where portage is building autoconf - 
/storage/tmp/portage/autoconf-2.53a/work/autoconf-2.53a/lib/m4sugar and run the
command its trying to execute by hand it works fine..
or when I type make in that
/storage/tmp/portage/autoconf-2.53a/work/autoconf-2.53a directory..

hope that helps a little bit
Comment 3 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-23 16:31:23 UTC
Hi Gerard Saraber .. you running gcc-3.1 ?
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-23 16:47:50 UTC
Btw, can any of you guys try m4-1.4o ?
Comment 5 Gerard Saraber 2002-05-23 17:55:21 UTC
Right, I'm using gcc 3.1, thats when this started ..
Comment 6 Matthew Kennedy (RETIRED) gentoo-dev 2002-05-23 18:01:44 UTC
I just tried m4o-2 and autoconf-2.53a. Same thing happens.

Perhaps we should just plain remove the check for m4 1.4 from autoconf?
Comment 7 Gerard Saraber 2002-05-23 18:36:35 UTC
i just tried with m4 1.4o too, same problem as well - 
its not the m4 check, autconf runs configure that checks for m4
it actually fails when running something during the compile thats where that
error shows up.
also - when i compile autoconf by hand it works fine, this only happens when
using emerge to install autoconf.
if i could only reproduce the problem by hand i'd have some way to track it down
but it only happens with emerge
Comment 8 Gerard Saraber 2002-05-24 11:52:34 UTC
ok we're getting closer - a machine here at work would install autoconf fine
even with gcc 3.1 but our home boxes wouldn't.
After installing Portage 1.9.13 (upgraded from 1.9.5) and installing Python
2.2.1 autoconf started giving the above error ..
going back to Python 2.2 and Portage 1.9.5 didn't fix it
so now we're going back to gcc 3.0 and seeing if Portage or Python compiled with
gcc 3.0 will fix it
Comment 9 Gerard Saraber 2002-05-24 13:09:22 UTC
Thats it! :)
portage does not work with gcc 3.1, so here's what we did to fix it:
gcc 3.1 is allready installed
install gcc 3.0
now gcc 3.0 is the default
we edited make.conf and set CFLAGS and CXXFLAGS and added our gcc 3.1 flags and
-V 3.1 to them
now you can emerge python to compile it with gcc 3.1
now emerge portage (portage doesnt use those make.conf flags and uses gcc 3.0)

after that emerge autoconf works
Comment 10 Matthew Kennedy (RETIRED) gentoo-dev 2002-05-24 13:33:06 UTC
Cool! I started to think it was a portage problem too last night when seeing
several ebuild fail inside emerge, but compile fine outside.

But do you have any clues as to why portage fails for gcc3.1?
Comment 11 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-24 15:18:08 UTC
Seems like the problem devs/users have been having with
autoconf merging, is not related to m4, or even autoconf
for that matter at all.

The problem is that gcc-3.1 generates a bad sandbox and/or  It causes functions like fgets() to misbehave,
thus causing string strstr()'s to fail among things.

For example, not even man or info works:

[09:58] <Spidler> Darkmere / # man gcc 
[09:58] <Spidler> fgets: Bad address 
[09:58] <Spidler> Error reading man page /usr/share/man/man1/gcc.1.gz 
[09:58] <Spidler> No manual entry for gcc 
Comment 12 Matthew Kennedy (RETIRED) gentoo-dev 2002-05-25 00:37:19 UTC

You probably know this already, but for other users searching bugs for a
workaround, here's what i did (credit to Spider for the solution):

Get a portage tbz2 from a machine that has gcc2.95.3 installed, and 
   emerge --usepkg  portage

Then your gcc3.1 machine won't fail emerging a slew of packages (autoconf,
xfree, kdebase, orbit, just to name a few).

Comment 13 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-25 17:01:49 UTC
*** Bug 3018 has been marked as a duplicate of this bug. ***
Comment 14 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-25 17:27:54 UTC
*** Bug 2979 has been marked as a duplicate of this bug. ***
Comment 15 Antonio D'souza 2002-05-26 06:32:50 UTC
So does this mean that Portage will be borked until the gcc developers get that
bad sandbox bug fixed?
Comment 16 Martin Schlemmer (RETIRED) gentoo-dev 2002-05-26 07:47:59 UTC
Or we fix ours to compile properly with 3.1.  Or maybe develop another
sandbox.  Currently you can use a packaged portage that was compiled
with gcc-3.0.4 or gcc-2.95.3.  For example, just unpack the one
in ${FILESDIR} in your /.
Comment 17 Brandon Low (RETIRED) gentoo-dev 2002-05-29 01:58:07 UTC
$.02 here this broke when running a convertee system, but worked fine on a fresh
3.1 system...
Comment 18 Brandon Low (RETIRED) gentoo-dev 2002-06-04 07:00:52 UTC
Sandbox does break on my system, it was confused previously. Sorry.
Comment 19 Martin Schlemmer (RETIRED) gentoo-dev 2002-06-13 15:23:56 UTC
Ok, guys, I am not sure what in here is the fix, but I think I got sandbox
working with gcc-3.1!!

I recompiled gcc-3.1 with CFLAGS=CXXFLAGS="-O2 -march=i686 -pipe" and then
edited portage-1.9.13.ebuild to build sandbox with gcc-3.1 and
CFLAGS="-O2 -march=i486 -pipe", and it worked !!!!

I can merge autoconf no problem, and man works under sandbox now!!!

Comment 20 Martin Schlemmer (RETIRED) gentoo-dev 2002-06-13 16:04:19 UTC
OK, seems like sandbox only needs to be compiled with CFLAGS="-O2 -march=i486
Comment 21 Martin Schlemmer (RETIRED) gentoo-dev 2002-06-13 16:07:38 UTC
All gcc-3.1 users please try portage-1.9.13-r1, with "sandbox" added to
$FEATUES after you updated portage, thanks.
Comment 22 Brandon Low (RETIRED) gentoo-dev 2002-07-09 09:11:31 UTC
Martin, this is fixed with your fine grained sandboxing and other recent portage
fixes, right?  Can we clear this out of bugzilla?
Comment 23 Antonio D'souza 2002-07-09 10:09:08 UTC
Well, it works for me now, anyway.
Comment 24 Martin Schlemmer (RETIRED) gentoo-dev 2002-07-09 13:21:31 UTC
The fix for this one is basically just to compile the sandbox with
CFLAGS="-O2 -march=i486 -pipe".

The fine grained stuff is for bug #1599.

Anyhow, this seems to be fixed, so marking as such.
Comment 25 Martin Schlemmer (RETIRED) gentoo-dev 2002-08-03 00:30:04 UTC
*** Bug 5947 has been marked as a duplicate of this bug. ***