RE: gcc bootstrapping problem

[Post, Mark K]

You said 'In the log above, they are invoking xgcc in such a way that it
expects
"C-code", i.e. it implicitly calls the "C-driver".'  Except "they," i.e.,
gcc, are not invoking it.  The ltconfig script is, trying to do it's own
thing.  I don't think the gcc developers are responsible for what configure,
libtool and ltconfig do after they are invoked.  The problem occurs after
gcc and g++ are built, and is doing some configuring for libjava.

I am not a gcc developer.  I am a distribution maintainer (for Slack/390),
trying to build a 64-bit version of gcc 3.3.4.  I'm not modifying anything
(other than applying a couple of gcc patches), just doing this:
   mkdir gcc.build.lnx
   cd gcc.build.lnx
   ../gcc-$VERSION/configure --prefix=/usr \
               --enable-shared \
               --enable-threads=posix \
               --enable-__cxa_atexit \
               --disable-checking \
               --with-gnu-ld \
               --verbose \
               --target=s390x-slackware-linux \
               --host=s390x-slackware-linux
   make

(I tried to do a "make bootstrap" but died an early and ugly death.)


Mark Post
  
-----Original Message-----
From: Ralf Corsepius [mailto:address@hidden
Sent: Sunday, September 19, 2004 2:04 AM
To: Post, Mark K
Cc: 'address@hidden'
Subject: Re: gcc bootstrapping problem


On Sat, 2004-09-18 at 18:41, Post, Mark K wrote:
> Hi,
> 
> I'm trying to create a native 64-bit compiler for Slack/390.  I downloaded
> some existing ones from the Fedora project to get me started.  I ran into
a
> problem with them.  That is, far, far along into the build, the make
process
> starts to configure in the s390x-slackware-linux/libjava/ directory, and
it
> invokes ltconfig.  The ltconfig script issues this command, and gets the
> error shown:
> ltconfig:1487:  /tmp/build-gcc-3.3.4-s390x-1/gcc.build.lnx/gcc/xgcc
> -shared-libgcc -B/tmp/build-gcc-3.3.4-s390x-1/gcc.build.lnx/gcc/
-nostdinc++
>
-L/tmp/build-gcc-3.3.4-s390x-1/gcc.build.lnx/s390x-slackware-linux/libstdc++
> -v3/src
>
-L/tmp/build-gcc-3.3.4-s390x-1/gcc.build.lnx/s390x-slackware-linux/libstdc++
> -v3/src/.libs -B/usr/s390x-slackware-linux/bin/
> -B/usr/s390x-slackware-linux/lib/ -isystem
> /usr/s390x-slackware-linux/include -o conftest -g -O2 -D_GNU_SOURCE
> -fno-builtin -fno-rtti -fno-exceptions   conftest.cc conftstm.o 1>&5
> conftstm.o(.eh_frame+0x11): In function `main':
>
/tmp/build-gcc-3.3.4-s390x-1/gcc.build.lnx/s390x-slackware-linux/libjava/con
> ftest.cc:9: undefined reference to `__gxx_personality_v0'
> collect2: ld returned 1 exit status
> 
> According to a conversation I had with a gcc developer, the issue is
> "ltconfig is
> attempting to use the C driver (xgcc) to build and link a C++ program;
this
> is the reason of the failure."
This is only half of the story.

Yes, it is using "xgcc", but "xgcc" is not the "C driver". "xgcc" is a
temporary, gcc-buildtree local version of the "to-be-built gcc".
In the log above, they are invoking xgcc in such a way that it expects
"C-code", i.e. it implicitly calls the "C-driver"

To be able to compile and link C++ files, they either must be using a
corresponding temporary, local "xg++" (AFAIK, such thing does not exist)
or pass the appropriate language options to xgcc (Probably something
like "xgcc -x c++").

So, IMO, this is a problem in GCC's way to set up CXX.

> I'm using libtool 1.5.6 on this system.
Are you a gcc-developer rebuilding auto*tool generated files inside of
GCC's sourcetree (Bootstrapping gcc's sourcedir) or a user trying to
build gcc (bootstrapping gcc)? In the latter case, this should not
matter, because GCC ships with prebuild files, you don't really want to
touch. 

>   I tried searching for prior bug
> reports, but didn't come across any.  It was pretty late at night, though,
> and I could have missed one.
> 
> If this is a known issue, I'll upgrade to the latest released version.
IMO, this is not a libtool bug, but a problem with GCC's configure
scripts.

Ralf