GCC_4.2.0 problem

Hi,

I have seen the bug
http://llvm.org/bugs/show_bug.cgi?id=896

Maybe it is a non-issue but I had some trouble with this.

I am running Debian sid and were no longer able to compile llvm.

/home/fred/llvm/build/gcc/xgcc: /home/fred/llvm/build/gcc/libgcc_s.so.1:
version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)

The installed version have this symbol.

strings /lib/libgcc_s.so.1 | grep GCC
GCC_3.0
GCC_3.3
GCC_3.3.1
GCC_3.4
GCC_3.4.2
GCC_4.0.0
GCC_4.2.0

It is just the LD_LIBRARY_PATH that brings in the "llvm" libgcc_s.so.1
that breaks the compilation.

I added this to my build script and now llvm builds properly.

cd build
../llvm-gcc4/configure --prefix=$LLVM/install --enable-llvm=$LLVMOBJDIR
--enable-languages=c --disable-threads
sed -i 's/LD_LIBRARY_PATH/DUMMY_LD_LIBRARY_PATH_DUMMY/g' Makefile
make
make install

The bugreport mentions this, but since the Makefile is not there before make,
one save oneself an make/make clean trip.

Hopefully it helps someone that is fighting with this problem.
I am not sure if it gives any sideeffects but I have not seen any so far.

/Fred

Fredrik Svensson wrote:

It is just the LD_LIBRARY_PATH that brings in the "llvm" libgcc_s.so.1
that breaks the compilation.

I added this to my build script and now llvm builds properly.

cd build
../llvm-gcc4/configure --prefix=$LLVM/install --enable-llvm=$LLVMOBJDIR
--enable-languages=c --disable-threads
sed -i 's/LD_LIBRARY_PATH/DUMMY_LD_LIBRARY_PATH_DUMMY/g' Makefile
make
make install

The bugreport mentions this, but since the Makefile is not there before make,
one save oneself an make/make clean trip.

Hopefully it helps someone that is fighting with this problem.
I am not sure if it gives any sideeffects but I have not seen any so far.

Thanks for that workaround. What I've been doing is copying
/lib/libgcc_s.so.1 over LLVM's copy and rebuilding xgcc.

A long-term fix for this would be nice.

Why does llvm-gcc build its own libgcc_s.so? Would we have the same
problem if we tried to build FSF GCC 4.01, or is this problem LLVM-specific?

Nick

Thanks for that workaround. What I've been doing is copying
/lib/libgcc_s.so.1 over LLVM's copy and rebuilding xgcc.

A long-term fix for this would be nice.

I'm not hitting this, so I'm relying on you guys to figure out what the right solution is.

Why does llvm-gcc build its own libgcc_s.so? Would we have the same
problem if we tried to build FSF GCC 4.01, or is this problem LLVM-specific?

libgcc is part of the GCC distro. My (possibly flawed) understanding of the issue is that GCC generates code that contains calls into libgcc. This means that any code compiled with llvm-gcc should used llvm-gcc's libgcc. It's quite possible that the GCC build is getting confused and building cc1 with the system gcc but trying to use llvm-gcc's libgcc or opposite.

-Chris

Chris Lattner wrote:

Why does llvm-gcc build its own libgcc_s.so? Would we have the same
problem if we tried to build FSF GCC 4.01, or is this problem LLVM-specific?

libgcc is part of the GCC distro. My (possibly flawed) understanding of
the issue is that GCC generates code that contains calls into libgcc.
This means that any code compiled with llvm-gcc should used llvm-gcc's
libgcc. It's quite possible that the GCC build is getting confused and
building cc1 with the system gcc but trying to use llvm-gcc's libgcc or
opposite.

The problem is that the system standard libstdc++.so.6 has extern
symbols that it expects to be resolved by linking against libgcc_s. In
an FSF build, xgcc doesn't link to libstdc++.

(As an aside, most programs compiled with g++ link to libstdc++ but not
libgcc_s. I'm not clear on how that works for other programs, but not xgcc?)

Nick

Ah, so you're saying that LLVM's cc1 (which is a C++ program) is linking in the system libstdc++ but the llvm-gcc libgcc? That is bad.

-Chris