| Summary: | our m4 breaks latest autoconf-2.53 at emerge | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthew Kennedy (RETIRED) <mkennedy> |
| Component: | [OLD] GCC Porting | Assignee: | Martin Schlemmer (RETIRED) <azarah> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gsaraber, kryptolus, mkennedy, seemant, wmertens |
| Priority: | High | ||
| Version: | 1.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Matthew Kennedy (RETIRED)
2002-05-22 15:39:34 UTC
Weird thing is .. it works fine here, bleh. 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 Hi Gerard Saraber .. you running gcc-3.1 ? Btw, can any of you guys try m4-1.4o ? Right, I'm using gcc 3.1, thats when this started .. 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? 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 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 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 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? 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 libsandbox.so. 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 Azarah, 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). Matt *** Bug 3018 has been marked as a duplicate of this bug. *** *** Bug 2979 has been marked as a duplicate of this bug. *** So does this mean that Portage will be borked until the gcc developers get that bad sandbox bug fixed? 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 /.
$.02 here this broke when running a convertee system, but worked fine on a fresh 3.1 system... Sandbox does break on my system, it was confused previously. Sorry. 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!!! OK, seems like sandbox only needs to be compiled with CFLAGS="-O2 -march=i486 -pipe". All gcc-3.1 users please try portage-1.9.13-r1, with "sandbox" added to $FEATUES after you updated portage, thanks. Martin, this is fixed with your fine grained sandboxing and other recent portage fixes, right? Can we clear this out of bugzilla? Well, it works for me now, anyway. 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. *** Bug 5947 has been marked as a duplicate of this bug. *** |