Bug 2979 – gcc3.1 and xfree86-4.2.0-r10/9 partial success -- a problem with portage perhaops?

• Status: RESOLVED DUPLICATE of bug 2929
• Product: Portage Development

[Description Matthew Kennedy (RETIRED) 2002-05-24 00:00:08 UTC]

XFree86-4.2-r10 (and even -r9) *will* build under gcc3.1 for me but there
appears to be a problem using emerge to do it. Here's what I did:

  ebuild /usr/portage/x11-base/xfree-4.2.0-r10.ebuild unpack
  cd /var/tmp/portage/..../xfree-4.2.0-r10/xc
  make World
  cd nls && make (if you want nls)
  cd /
  ebuild /usr/portage/x11-base/xfree-4.2.0-r10.ebuild install qmerge
 
Now, using emerge:

sartre root # emerge xfree
Calculating dependencies ...done!
>>> emerge x11-base/xfree-4.2.0-r10 to /
>>> md5 ;-) X420src-1.tgz
>>> md5 ;-) X420src-2.tgz
>>> md5 ;-) X420src-3.tgz
>>> md5 ;-) 4.2.0-xlib-i18n-module.patch
>>> md5 ;-) 4.2.0-zlib-security.patch
>>> md5 ;-) 4.2.0-libGLU-bad-extern.patch
>>> md5 ;-) truetype.tar.gz
>>> Unpacking source...
>>> Unpacking X420src-1.tgz
>>> Unpacking X420src-2.tgz
>>> Unpacking X420src-3.tgz
patching file xc/lib/X11/XlcDL.c
patching file xc/lib/zlib/infblock.c
patching file xc/extras/ogl-sample/main/gfx/lib/glu/libnurbs/nurbtess/quicksort.cc
patching file xftfreetype.c
patching file xftglyphs.c
>>> Source unpacked.

Building Release 6.6 of the X Window System.

I hope you checked the configuration parameters in ./config/cf
to see if you need to pass BOOTSTRAPCFLAGS.

Fri May 24 00:02:43 CDT 2002

cd ./config/imake && make - --jobserver-fds=3,4 -j -f Makefile.ini
BOOTSTRAPCFLAGS="" CC="cc" clean
make[1]: Entering directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc/config/imake'
rm -f ccimake imake.o imake
rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#*
rm -f -r Makefile.proto Makefile Makefile.dep bootstrap
make[1]: Leaving directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc/config/imake'
make - --jobserver-fds=3,4 -j Makefile.boot
make[1]: Entering directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc'
cd ./config/imake && make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 -j -f
Makefile.ini BOOTSTRAPCFLAGS="" CC="cc"
make[2]: Entering directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc/config/imake'
cc -o ccimake  -O -I../../include -I../../imports/x11/include/X11 ccimake.c
making imake with BOOTSTRAPCFLAGS= in config/imake
cc -c  -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c
cc -o imake  -O -I../../include -I../../imports/x11/include/X11 imake.o
make[2]: Leaving directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc/config/imake'
rm -f ./config/makedepend/Makefile.proto
./config/imake/imake -I./config/cf  -s ./config/makedepend/Makefile.proto -f
./config/makedepend/Imakefile -DTOPDIR=../.. -DCURDIR=./config/makedepend
make[1]: *** [config/makedepend/Makefile.proto] Aborted
make[1]: *** Deleting file `config/makedepend/Makefile.proto'
make[1]: Leaving directory `/var/tmp/portage/xfree-4.2.0-r10/work/xc'
make: *** [World] Error 2

[Comment 1 Matthew Kennedy (RETIRED) 2002-05-24 00:02:08 UTC]

my config is a default-1.0-gcc3 profile migrated from gcc3.0.4 to gcc3.1 (by
unmerging gcc3.0.4 altogther)

[Comment 2 Gerard Saraber 2002-05-24 13:16:57 UTC]

(also see bug #2929 http://bugs.gentoo.org/show_bug.cgi?id=2929 )
when you build portage with gcc 3.0 emerge xfree works

[Comment 3 Martin Schlemmer (RETIRED) 2002-05-24 15:19:32 UTC]

Try to build it outside of portage, as it could be a gcc-3.1/sandbox issue

[Comment 4 Martin Schlemmer (RETIRED) 2002-05-24 15:21:04 UTC]

Whoops, ill read better next time.  AFAIK, it is a portage problem, but more
specific, gcc-3.1 generates a bad sandbox.

[Comment 5 Gerard Saraber 2002-05-24 15:37:12 UTC]

Thats what pointed us to portage/sandbox in the first place, automake, glibc and
xfree would build just fine by hand, but not inside the emerge sandbox

[Comment 6 Gerard Saraber 2002-05-24 15:38:55 UTC]

oops make that autoconf, not automake, automake has worked fine the whole time
as far as I could tell

[Comment 7 Martin Schlemmer (RETIRED) 2002-05-24 16:11:42 UTC]

Ill include my post to the developers here as well, if somebody can
debug sandbox/gcc3.1.

------------------------snip-----------------------------------
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 

Solution:

1) Dont use gcc-3.1 ... I dont think so :/
2) Fix sandbox ... I am not up to it, sad but true.
---------------------snip--------------------------------------

[Comment 8 Martin Schlemmer (RETIRED) 2002-05-25 17:27:53 UTC]

This is an extension of bug #2929, or at least the same cause.

*** This bug has been marked as a duplicate of 2929 ***