Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1805 - groff fails to build during "bootstrap.sh" or during "emerge system"
Summary: groff fails to build during "bootstrap.sh" or during "emerge system"
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: Highest blocker (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-15 14:22 UTC by Sean P. Kane
Modified: 2005-02-06 06:50 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sean P. Kane 2002-04-15 14:22:35 UTC
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
Comment 1 Sean P. Kane 2002-04-15 14:35:42 UTC
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
Comment 2 Sean P. Kane 2002-04-15 15:38:29 UTC
I am actually installing 1.1a NOT 1.0.
Comment 3 Daniel Robbins (RETIRED) gentoo-dev 2002-04-16 00:18:19 UTC
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.
Comment 4 Sean P. Kane 2002-04-25 12:41:44 UTC
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
Comment 5 Sean P. Kane 2002-04-25 17:47:17 UTC
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
Comment 6 Chris Arndt 2002-04-25 20:47:49 UTC
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.
Comment 7 Chris Arndt 2002-04-25 21:16:05 UTC
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 .
Comment 8 Brandon Low (RETIRED) gentoo-dev 2002-04-26 16:34:08 UTC
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.
Comment 9 Arnold de Bruijn 2002-04-30 12:52:57 UTC
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
Comment 10 Sean P. Kane 2002-04-30 18:34:10 UTC
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".
Comment 11 Sean P. Kane 2002-05-01 11:42:42 UTC
The above workaround worked fine for me. I am no doing the rest of the install 
without a problem.

Sean
Comment 12 Daniel Robbins (RETIRED) gentoo-dev 2002-05-02 22:28:21 UTC
These problems are all caused by: 1) forgetting to bootstrap, 2) mistakenly
adding "build" to your custom USE variable.  Closing this bug.
Comment 13 Chris Arndt 2002-05-02 23:17:17 UTC
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
Comment 14 Sean P. Kane 2002-05-03 10:43:37 UTC
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
Comment 15 Chris Arndt 2002-05-03 17:04:32 UTC
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"
Comment 16 Daniel Robbins (RETIRED) gentoo-dev 2002-05-04 17:56:37 UTC
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! :)
Comment 17 Chris Arndt 2002-05-04 18:04:30 UTC
drob,

no problem, and thanks for working with us on this issue as well.

later,
chris
Comment 18 Sean P. Kane 2002-05-06 10:54:01 UTC
Very glad we got it fixed. Thanks for your help Daniel!

Sean
Comment 19 Adam Piontek 2002-06-29 16:29:19 UTC
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?
Comment 20 Greg Coit 2002-06-29 19:58:56 UTC
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
Comment 21 Mark Guertin 2002-06-30 21:54:45 UTC
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

Comment 22 Martin Schlemmer (RETIRED) gentoo-dev 2002-07-02 13:39:24 UTC
Yep, know about the problem.  I did the fixes last night .. bootstrap should
also try to do texinfo, and that should be -r4.
Comment 23 Steven Wong 2002-08-02 06:07:20 UTC
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.
Comment 24 meyerm 2005-01-12 07:31:30 UTC
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...

Comment 25 Stan Behrens 2005-01-12 09:58:29 UTC
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''
Comment 26 Fernando (likewhoa) 2005-02-06 03:23:57 UTC
ok if you want groff to emerge on bootstrap, just emerge gcc-config before you bootstrap and you will be ok,....