I'm trying to use gcc4.1.2 (20060901 prerelease) to build llvm-gcc. Unfortunately, I get a missing symbol error in the build process: /home/nicholas/llvm-gcc/build/gcc/xgcc: /home/nicholas/llvm-gcc/build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6) make[1]: *** [specs] Error 1 make[1]: Leaving directory `/home/nicholas/llvm-gcc/build/gcc' make: *** [all-gcc] Error 2 I'm not sure what else to say about this. I also have a /usr/lib/libstdc++.so.5 which I assume is for older compilers. My /usr/lib/libstdc++.so is a symlink to libstdc++.so.6.0.8.
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 <prefix>/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