Summary: | sys-devel/clang-3.0-r3 fails to compile Hello World due to linker issues | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Richard Yao (RETIRED) <ryao> |
Component: | FreeBSD | Assignee: | Richard Yao (RETIRED) <ryao> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bsd+disabled, voyageur |
Priority: | Normal | Keywords: | Bug |
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
See Also: | http://llvm.org/bugs/show_bug.cgi?id=12955 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 417031 | ||
Bug Blocks: | 408963 |
Description
Richard Yao (RETIRED)
2012-03-22 06:26:03 UTC
Actually, I executed that in the wrong terminal. It only works around one of the linking issues, not all of them. On Gentoo/FreeBSD, we need to do the following to be free of issues: ln -s /usr/lib/gcc/i686-gentoo-freebsd9.0/4.6.2/crtend.o /usr/lib/crtend.o ln -s /usr/lib/gcc/i686-gentoo-freebsd9.0/4.6.2/crtbegin.o /usr/lib/crtbegin.o ln -s /usr/lib/gcc/i686-gentoo-freebsd9.0/4.6.2/crtbeginS.o /usr/lib/crtbeginS.o ln -s /usr/lib/gcc/i686-gentoo-freebsd9.0/4.6.2/crtendS.o /usr/lib/crtendS.o ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so On Gentoo Linux, `ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so` will help, but it is not enough to workaround it. Yes, for Gentoo/notLinux the hardcoded paths everywhere will probably cause many problems. On standard arches though, clang works well (just remerged it to check) Two things bother me here: * ignoring nonexistent directory "/include" * no additional paths pointing to /usr/lib/gcc/x86_64-pc-linux-gnu/* in the verbose output: these should have been added at configure time (with some calls to gcc-config in stable ebuilds). What was the configure command line when you emerged it? clang-999 'autodetects' the gcc paths, but it lost the possibility to specify a gcc version (it always pick up the latest), bug #406163 (In reply to comment #2) > * no additional paths pointing to /usr/lib/gcc/x86_64-pc-linux-gnu/* in the > verbose output: these should have been added at configure time (with some > calls to gcc-config in stable ebuilds). What was the configure command line > when you emerged it? On amd64 Gentoo Linux, the configure line is as follows: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --enable-shared --with-optimize-option= --enable-optimized --disable-assertions --disable-expensive-checks --enable-targets=host-only --enable-pic --with-c-include-dirs=/usr/include:/include --with-cxx-include-root=/include/g++-v4 --with-cxx-include-arch=x86_64-pc-linux-gnu --with-cxx-include-32bit-dir=/32 (In reply to comment #3) > --with-c-include-dirs=/usr/include:/include > --with-cxx-include-root=/include/g++-v4 Hmm so it does not find gcc prefix path (from the ebuild): local CXX_PATH=$(gcc-config -L| cut -d: -f1) CONF_FLAGS="${CONF_FLAGS} --with-c-include-dirs=/usr/include:${CXX_PATH}/include" CONF_FLAGS="${CONF_FLAGS} --with-cxx-include-root=${CXX_PATH}/include/g++-v4" Strange that gcc-config does not show anything on your system (In reply to comment #4) > (In reply to comment #3) > > --with-c-include-dirs=/usr/include:/include > > --with-cxx-include-root=/include/g++-v4 > > Hmm so it does not find gcc prefix path (from the ebuild): > local CXX_PATH=$(gcc-config -L| cut -d: -f1) > CONF_FLAGS="${CONF_FLAGS} > --with-c-include-dirs=/usr/include:${CXX_PATH}/include" > CONF_FLAGS="${CONF_FLAGS} --with-cxx-include-root=${CXX_PATH}/include/g++-v4" > > Strange that gcc-config does not show anything on your system `gcc-config -L| cut -d: -f1` returns /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3 on my Linux system. It seems that I had upgraded GCC and removed the older version. This broke Clang because it had the older version set at build time. After a chat with voyageur, I am reassigning this bug to myself and CCing the BSD team. FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects this. Consequently, Clang will not work without it. At present, I have Clang working on my local system with some modifications to sys-freebsd/freebsd-lib to install those components as FreeBSD does. I will attach a modified ebuild in a day or two. What I currently have locally is hackish and I do not feel it is ready for inclusion into the tree. (In reply to comment #6) > After a chat with voyageur, I am reassigning this bug to myself and CCing > the BSD team. > > FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects crt*.o are correct here, libgcc and libstdc++ are not if you want to be able to install multiple gcc versions (In reply to comment #7) > (In reply to comment #6) > > After a chat with voyageur, I am reassigning this bug to myself and CCing > > the BSD team. > > > > FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects > > crt*.o are correct here, libgcc and libstdc++ are not if you want to be able > to install multiple gcc versions I am testing it and so far, GCC does not seem to care. Its build system hard codes the locations of its own libgcc and libstdc++, so it ignores the system ones. However, I have encountered a few regressions. One is that modern g++ binaries are incapable of building the version of libstdc++ that FreeBSD uses. It produces errors on valid C++ code, so this is a regression in g++. The second is that I somehow broke PAM. I am still looking into the cause. I plan to fix both regressions before I post patches. (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > After a chat with voyageur, I am reassigning this bug to myself and CCing > > > the BSD team. > > > > > > FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects > > > > crt*.o are correct here, libgcc and libstdc++ are not if you want to be able > > to install multiple gcc versions > > I am testing it and so far, GCC does not seem to care. Its build system hard > codes the locations of its own libgcc and libstdc++, so it ignores the > system ones. define system ones. if gcc expects the libgcc* it provides, builds programs expecting this abi, and the program is linked with a random one from /usr/lib, with a different abi, you can expect random to break... > However, I have encountered a few regressions. One is that modern g++ > binaries are incapable of building the version of libstdc++ that FreeBSD > uses. It produces errors on valid C++ code, so this is a regression in g++. the libstdc++ in fbsd is from gcc 4.2.1... lets keep it dead... bringing in libc++ would be a much more valuable effort (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > > After a chat with voyageur, I am reassigning this bug to myself and CCing > > > > the BSD team. > > > > > > > > FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects > > > > > > crt*.o are correct here, libgcc and libstdc++ are not if you want to be able > > > to install multiple gcc versions > > > > I am testing it and so far, GCC does not seem to care. Its build system hard > > codes the locations of its own libgcc and libstdc++, so it ignores the > > system ones. > > define system ones. GCC bundles these components and installs them in its own directory subtree, but in FreeBSD, they are system components found in /usr/lib. > if gcc expects the libgcc* it provides, builds programs expecting this abi, > and the program is linked with a random one from /usr/lib, with a different > abi, you can expect random to break... It links against libgcc.a, so there is no problem. > > However, I have encountered a few regressions. One is that modern g++ > > binaries are incapable of building the version of libstdc++ that FreeBSD > > uses. It produces errors on valid C++ code, so this is a regression in g++. > > the libstdc++ in fbsd is from gcc 4.2.1... lets keep it dead... > bringing in libc++ would be a much more valuable effort Unfortunately, Clang expects these components to be in /usr/lib, which causes it to break. An alternative solution would be to modify gcc-config to install symlinks in /usr/lib. That could also address bug #406163. How does that sound? (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > (In reply to comment #6) > > > > > After a chat with voyageur, I am reassigning this bug to myself and CCing > > > > > the BSD team. > > > > > > > > > > FreeBSD installs crt*.o, libgcc and libstdc++ in /usr/lib and Clang expects > > > > > > > > crt*.o are correct here, libgcc and libstdc++ are not if you want to be able > > > > to install multiple gcc versions > > > > > > I am testing it and so far, GCC does not seem to care. Its build system hard > > > codes the locations of its own libgcc and libstdc++, so it ignores the > > > system ones. > > > > define system ones. > > GCC bundles these components and installs them in its own directory subtree, since they are part of gcc, its pretty normal... gcc on gentoo does this to allow multiple gcc versions to be installed, switched, and used sanely. > but in FreeBSD, they are system components found in /usr/lib. components found in /usr/lib are from gcc 4.2.1... it is a problem that should be fixed in freebsd, not a route to follow. > > if gcc expects the libgcc* it provides, builds programs expecting this abi, > > and the program is linked with a random one from /usr/lib, with a different > > abi, you can expect random to break... > > It links against libgcc.a, so there is no problem. not really; dynamically loading or statically linking something with an abi you dont expect is in the end the same thing... > > > > However, I have encountered a few regressions. One is that modern g++ > > > binaries are incapable of building the version of libstdc++ that FreeBSD > > > uses. It produces errors on valid C++ code, so this is a regression in g++. > > > > the libstdc++ in fbsd is from gcc 4.2.1... lets keep it dead... > > bringing in libc++ would be a much more valuable effort > > Unfortunately, Clang expects these components to be in /usr/lib, which > causes it to break. An alternative solution would be to modify gcc-config to > install symlinks in /usr/lib. That could also address bug #406163. How does > that sound? you should ask this to toolchain@ but im pretty sure they have good reasons not to do so PS: this bug has absolutely nothing to do with bsd... (In reply to comment #11) > PS: this bug has absolutely nothing to do with bsd... Good point. I am reassigning it to myself. Also, a fix for this issue was committed to CVS as part of sys-devel/clang-3.1-r1. |