Groff fails to build complaining that there is no working c++ on the system when extecuting 'emerge system' or even simply 'emerge groff'. I tried symlinking gcc to g++ but that didn't help. I am pretty new to Gentoo although a long time unix user and would be happy to provde more details. I am installing 1.0a and am using the gcc ( make.conf )optimizations that make binaries that only run on a P6. I have a Toshiba 5005-S507 laptop. Thanks, Sean spkane@genomatica.com
It looks like the conftest.sh file is missing and I'm assuming this creates conftest.c, so without this all the tests in 'configure' are failing. Sean
I am actually installing 1.1a NOT 1.0.
OK... I think this was because one of our new developers put something in our portage tree that he shouldn't have. It's been fixed. If you try to install again, it should work. Sorry for the inconvenience.
This bug has re-appeared. I tried to do a new install today and groff seems to be broken again. It complains that the C++ compiler is bad. My sys-apps/groff directory has the ebuild for groff 1.16.1-r1 and 1.17.2-r1. the bootstrap is trying to build 1.17.2-r1 when it fails. If I remove the 1.17 ebuild file should that temporarily fix this problem? And also, is it safe to just re-run scripts/bootstrap.sh after it has failed like this? Thanks, Sean
I have tried masking the 1.17.2 groff and I still get the same error with the older version. I noticed there was no /usr/bin/g++, so it tried link that to /usr/bin/gcc and it didn't make any significant difference. The build still fails saying that the C++ compiler doesn't work. I'd guess that this is the problem again "It looks like the conftest.sh file is missing and I'm assuming this creates conftest.c, so without this all the tests in 'configure' are failing." Sean
I'm getting the same issue. It appears to be more of an issue with gcc. If I start with the stage2, that already had gcc compliled, then I don't run into this problem. I talked to some others on #gentoo that mentioned that they saw similar issues with compiling gcc.
checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking that C++ compiler can compile simple program... no configure: error: a working C++ compiler is required !!! ERROR: The ebuild did not complete successfully. !!! Function src_compile, Line 1, Exitcode 1 !!! (no error message) !!! emerge aborting on /usr/portage/sys-apps/groff/groff-1.17.2-r1.ebuild .
This bug is caused because in order for autoconf to exist, which is needed for the full gcc-3 build, a c++ compiler needs to exist first, but the "USE=build" versoin of gcc DOES NOT compile c++ the only work around that I have found is to partially bootstrap a gcc-2 and then go back and do gcc3 after autoconf and groff are built. Hope this helps.
Two days ago I also experienced this problems during the bootstrap of Gentoo 1.1a, what worked for me was to manually "emerge gcc" and then do an "emerge groff" Maybe this info is usefull for some of you. Greetz, Arnold
I thikn I discovered a "clean" workaround for the moment. After doing your initial "emerge rsync" go into /usr/portage/sys-dev/gcc and edit the ebuilds in there. Replace any line that says "--enable-languages=c" to "--enable- languages=c,c++" this causes gcc to be built with C and C++ support when "USE=BUILD" (i.e. when running bootstrap.sh). My test of this isn't quite done, but I think it has already progressed past the problem spot. I'll update this tommorow. If this works, we'll have to fiqure out if this an appropraite change to just make to the gcc ebuild and if there is a more elegant fix (i.e. making it so g++ is NOT required for any of the packages used by "bootstrap.sh" and maybe "emerge system".
The above workaround worked fine for me. I am no doing the rest of the install without a problem. Sean
These problems are all caused by: 1) forgetting to bootstrap, 2) mistakenly adding "build" to your custom USE variable. Closing this bug.
hmm, intersting since i was seeing this problem during the bootstrap process. also "build" was not in my use variables. sure wish i could figure out what i'm doing wrong. at the moment my work around was to use the stage2 build rather than stage1
Dnaiel, I appreciate your input on this, but your conclusion simply isn't true. It is happening to me and others during bootstrap, which is why I updated the title of this bug. When putting a bit of debugging code into the bootstrap.sh, it looked like it was failing doing some prereqs for $myGLIBC. I have no USE=build in my make.conf. The only place that gets set in my setup is temporarily by the bootstrap.sh file when it does it's work. I have my system running now, so I'm not in a hurry to go back and troubleshoot this more, but if I get vmware running soon, maybe I'll try it there. Sean
i'm using /usr/portage/profiles/default-1.0 following the instructions exactly except i'm not using a cd, but chrooting to build from stage1 or stage2. here's my /etc/make.conf # Copyright 2000-2002 Daniel Robbins, Gentoo Technologies, Inc. # Contains system settings for Portage system # Download sites # The main Gentoo Linux source mirror; specify as many space-separated mirrors # as you like. GENTOO_MIRRORS="http://www.ibiblio.org/gentoo" # The main Gentoo Linux Portage server; specify a single Portage server. #SYNC="rsync://rsync.gentoo.org/gentoo-portage" # An alternate download server if you prefer anoncvs. emerge dev-util/cvs # for cvs support in emerge. The password for this CVS server is empty -- # just hit Enter. #SYNC="cvs://:pserver:anonymous@gentoo.org:/home/anoncvs" # Build-time functionality USE="aalib acl afs alsa apm atlas bonobo crypt cups dga doc encode fbcon flash gb gd ggi ggz gtkhtml guile imap innodb ipv6 java lcms ldap libg++ libgda matrox mikmod mozaccess-builtin mozctl mozilla mozxmlterm mpeg mysql mas ncurses odbc oss pda pdflib pic plotutils postgres qtmt quicktime ruby samba slp snmp spell svga tcltk text truetype xface xml xml2 xmms zeo" # USE options are inherited from /etc/make.profile/make.defaults. To turn a USE # setting off, add a "-setting" to the USE variable here. To enable a setting, # add the setting name to the USE variable here. Separate USE toggles with # whitespace. # Host-specific settings # For optimization, the -mcpu= option will cause binaries to be optimized for a # particular x86 CPU, but will continue to work on all CPUs. The -march= # option, on the other hand, will instruct the compiler to use instuctions # specific to that particular CPU in order to enhance performance. Resultant # binaries will *not* run on other systems unless they are 100% compatible with # your processor's instruction set. For example, -march=i686 will produce # executables that do not execute on Pentium Classic or K6 systems, but will # run on Pentium Pro and "above" systems. -march=x automatically enables # -mcpu=x. # Examples: # Pentium Pro/Pentium II/Pentium III+/Pentium 4/Athlon optimized (but binaries # will run on any x86 system) CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=i686 -O3 -pipe" CXXFLAGS="-mcpu=i686 -O3 -pipe" # Pentium Pro/Pentium II/Pentium III+/Pentium 4/Athlon exclusive (binaries # will use the P6 instruction set and only run on P6+ systems) #CHOST="i686-pc-linux-gnu" #CFLAGS="-march=i686 -O3 -pipe" #CXXFLAGS="-march=i686 -O3 -pipe" # Pentium/Pentium MMX+ exclusive (requires a Pentium Classic or K6 or beyond) #CHOST="i586-pc-linux-gnu" #CFLAGS="-march=i586 -O3 -pipe" #CXXFLAGS="-march=i586 -O3 -pipe" # K6 exclusive (requires a K6 or beyond) #CHOST="i586-pc-linux-gnu" #CFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" #CXXFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" #proxy settings PROXY(both), or HTTP_PROXY/FTP_PROXY #PROXY=freebox.gentoo.org:3128 #HTTP_PROXY= #FTP_PROXY= # Uncomment to use Lukemftp for download (the FreeBSD fetcher) # you need to merge lukemftp first! #FETCHCOMMAND='/usr/bin/lukemftp -s -a -o ${DISTDIR}/${FILE} ${URI}' #RESUMECOMMAND='/usr/bin/lukemftp -s -a -R -o ${DISTDIR}/${FILE} ${URI}' # Uncomment if you wanna use Prozilla for download # you need to merge prozilla first! #FETCHCOMMAND='/usr/bin/proz --no-getch -s ${URI} -P ${DISTDIR}' # Uncomment if you are a package maintainer with cvs access # The following fine grained configuration options are now available # digest : automatically create a digest for new ebuilds # cvs : automatically commit new digests to cvs # sandbox : enable the sandbox for path prefix otection # noclean : don't clean the temp dirs when emerge terminates # noauto : don't execute prior ebuild steps automatically # (eg. 'ebuild install' does just that and not # 'fetch unpack compile install' FEATURES="sandbox noauto"
OK, I'm pretty sure I tracked down the problem. The problem is that the "gd" USE variable fries bootstrap; I've removed support for "gd" from glibc and the problem should now be fixed on cvs. Thanks for keeping this bug open and politely correcting me when I was assuming it was user error. Apologies to all! :)
drob, no problem, and thanks for working with us on this issue as well. later, chris
Very glad we got it fixed. Thanks for your help Daniel! Sean
I'm trying to install Gentoo from the 1.2 x86 image, and it fails during the bootstrap, exactly as reported by others in this bug. I initially had gd in my USE settings, but when I found this bug (after searching the forums), since it said the problem had been with gd, I removed it from my USE settings and tried again. No go; it still stops at groff and complains about no C++ compiler. So I guess somebody broke this again?
I'm afraid this is broken again. I'm doing a clean install using 1.2. I didn'y add any use variables to the make.conf - only uncommented the athlon only. bootstrap dies at emerge of groff-1.17.2-r1.ebuild. Same error as above... Hope this helps... Greg Coit gregcoit@yahoo.com
I am seeing this problem as well trying to build a gcc-3.1 stage1 on PPC. In the same chroot I can emerge it manually, looks like some new DEP is messing things up again. No g++ compiler found. USE="build bootstrap" is what I'm running from scripts/autobuildimgppc.sh
Yep, know about the problem. I did the fixes last night .. bootstrap should also try to do texinfo, and that should be -r4.
checking whether g++ accepts -g... no checking that C++ compiler can compile simple program... no configure: error: a working C++ compiler is required Seems to be rearing its ugly head up again. :) I'm doing this from a fresh stage1 v1.3b tarball though.
Oh guys... Hi :-) I just wanted to bootstrap a 2004.3 stage1 (x86, no ~x86) and guess what happended... groff can't be built because of a missing g++. The binary /usr/bin/g++ isn't there...
checking that C++ compiler can compile simple program... no configure: error: a working C++ compiler is required !!! ERROR: sys-apps/groff-1.19.1-r2 failed. !!! Function src_compile, Line 85, Exitcode 1 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. after ''cd /usr/portage; scripts/bootstrap.sh''
ok if you want groff to emerge on bootstrap, just emerge gcc-config before you bootstrap and you will be ok,....
