Er, this seems to already be discussed:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-June/006164.html

Dropping bug. I'll reopen it if it just won't go away.

It would be nice to get this fixed in the llvm-gcc tree. Does gcc mainline have this makefile code? if not,
maybe we should just remove it?

-Chris

Modifying the Makefile doesn't fix this bug for me. I've removed my build
directory and started from scratch and I still can't get llvm-gcc built.

I'm seeing the same issue compiling WINE, which suggests that it isn't confined
to LLVM. My vendor has a bug open for this issue: http://bugs.debian.org/386121

This bug is being caused by the fact that the bootstrap-built compiler xgcc is
linked against build/gcc/libgcc_s.so.1, but /usr/lib/libstdc++.so.6.

This bug occurs when the /usr/lib/libstdc++.so.6 is incompatible with
build/gcc/libgcc_s.so.1 (host gcc is newer than llvm-gcc). Probably, the
complete fix is to always compile libstdc++ after compiling libgcc and before
compiling gcc itself.
A partial fix may be to port the gcc patch from pr26208 to llvm-gcc. This patch
includes the symbol (_Unwind_GetIPInfo) required by libstdc++6 of ubuntu edgy
(and probably many other distributions).

A quick workaround that has been working for me for a while is to configure
llvm-gcc with the --disable-shared option. Then the xgcc isn't going to link in
any libstdc++ or libgcc_s as they will be statically linked in.

I think the entire issue with this bug is LD_LIBRARY_PATH. llvm-gcc will look in
its /lib directory for libgcc_s.so and libstdc++.so, but only after
looking in any LD_LIBRARY_PATH directories. Normally one wouldn't include
/usr/lib in the LD_LIBRARY_PATH because it is already searched by ld.so.
However, in the case that you have your own compiler build that is different
from the system compiler, you need to set LD_LIBRARY_PATH to pick up its runtime
libraries when using a program it compiled. If that program is llvm-gcc, you get
the error message described by this bug.

There are several workarounds:

1. Install your compiler to /usr/local/, make ld.so look in /usr/local, and
   don't set LD_LIBRARY_PATH
2. Use the appropriate -L or -B options to xgcc (requires change to makefiles
   in llvm-gcc).
3. Configure llvm-gcc with -disable-shared.

Only #​2 is actionable in the llvm-gcc code base. The question is, do we want to
do this?

I just hit this again. The work-around in current llvm-gcc is to hack
build/gcc/libgcc.mk and comment out the one long line that compiles the library.
Search for the word "backup" then move to the beginning of that line and comment
it out.

Hi,

I'm trying to build llvm-gcc using the 2.8 source distribution.

I've also hit the problem where llvm-gcc wants to use the local installed copies of libstdc++.so.6 & libgcc_s.so.1.

However, I'm finding that the --disable-shared fix does not work. The binary created still wants to use the shared libs:

ldd llvm-gcc
linux-vdso.so.1 => (0x00007fff2b3fe000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ac0800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ac0400000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ac5c00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003ac0000000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ac4000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003abfc00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003abe400000)

I'm happy to edit any Makefiles to resolve the issue and would gladly welcome any pointers to which line(s) I should edit so that llvm-gcc uses the static versions of those libs that it builds.

Thanks,

Jeff.

LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore.

If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks!

-Chris