Currently when you install any version of llvm-gcc, you cannot prompt portage to replace the system libstdc++ with the one provided by llvm-gcc. This creates problems when attempting to self-host clang or remove vanilla gcc (I have my reasons for doing this). The fix could be implemented fairly easily by a use flag promting the llvm-gcc libstdc++ to be copied to /usr/lib Reproducible: Always Steps to Reproduce: 1.emerge llvm-gcc 2. 3. Actual Results: systems libstdc++ remains the one provided by gcc Expected Results: libstdc++ is replaced by the one provided by llvm-gcc
(In reply to comment #0) > Currently when you install any version of llvm-gcc, you cannot prompt portage > to replace the system libstdc++ with the one provided by llvm-gcc. This creates > problems when attempting to self-host clang or remove vanilla gcc (I have my > reasons for doing this). > > The fix could be implemented fairly easily by a use flag promting the llvm-gcc > libstdc++ to be copied to /usr/lib > > Reproducible: Always > > Steps to Reproduce: > 1.emerge llvm-gcc > 2. > 3. > > Actual Results: > systems libstdc++ remains the one provided by gcc > > Expected Results: > libstdc++ is replaced by the one provided by llvm-gcc > While trying to hack together a ebuild, I realized that the fix should allow llvm-gcc to install as though it were a vanilla gcc, replacing all related libraries and binaries (if possible)
Changed the bug title to properly reflect what the issue is. I am not sure if it would be easy to create a gcc profile for llvm-gcc, but it would be highly appreciated.
Hmm, yes this is probably doable, but this requires a lot of testing (like the new gcc versions masked in tree) and probably some toolchain update to allow "alternate" gcc. There were talks like that for icc support
(In reply to comment #3) > Hmm, yes this is probably doable, but this requires a lot of testing (like the > new gcc versions masked in tree) and probably some toolchain update to allow > "alternate" gcc. There were talks like that for icc support > Well, if you could do it, I certainly could test it :) It would be great to see the foundations laid for a more llvm friendly gentoo.
hmmm, yeah, letting gcc-config deal with it, is most probably the most simple approach that also works.
(In reply to comment #5) > hmmm, yeah, letting gcc-config deal with it, is most probably the most simple > approach that also works. > My thinking was that as llvm-gcc does everything that gcc does and uses the same libraries, creating a gcc-config wouldn't be hugely difficult.
Perhaps something like: # create gcc-config entry dodir /etc/env.d/gcc local gcc_envd_base="/etc/env.d/gcc/${CHOST}-llvm-${MY_PV}" gcc_envd_file="${ED}${gcc_envd_base}" echo "GCC_PATH=\"${BINPATH}\"" >> ${gcc_envd_file} # maybe this needs tweaking for multilib (llvm insists on being so) LDPATH="${LIBPATH}" echo "LDPATH=\"${LDPATH}\"" >> ${gcc_envd_file} echo "STDCXX_INCDIR=\"g++-v${GCC_VERS/\.*/}\"" >> ${gcc_envd_file} is_crosscompile && echo "CTARGET=${CTARGET}" >> ${gcc_envd_file} But it seems the ebuild needs some path changes to better match gcc's layout. So maybe this isn't as simple as I initially thought.
(In reply to comment #7) > Perhaps something like: > # create gcc-config entry > dodir /etc/env.d/gcc > local gcc_envd_base="/etc/env.d/gcc/${CHOST}-llvm-${MY_PV}" > gcc_envd_file="${ED}${gcc_envd_base}" > echo "GCC_PATH=\"${BINPATH}\"" >> ${gcc_envd_file} > # maybe this needs tweaking for multilib (llvm insists on being so) > LDPATH="${LIBPATH}" > echo "LDPATH=\"${LDPATH}\"" >> ${gcc_envd_file} > echo "STDCXX_INCDIR=\"g++-v${GCC_VERS/\.*/}\"" >> ${gcc_envd_file} > is_crosscompile && echo "CTARGET=${CTARGET}" >> ${gcc_envd_file} > But it seems the ebuild needs some path changes to better match gcc's layout. > So maybe this isn't as simple as I initially thought. I would have thought the only ebuild change required in that respect would be to src_install()? Or is there some added complexity? I know that GCC ebuilds use an ETYPE (I don't know how that works), could llvm-gcc possibly also utilize this?
My understanding of ebuilds is poor at best. but to try and get things moving I might try and throw something together later and do some testing to see if it resembles something functional.
If you want to play to try and see if you can get it sort of working, have a look at e.g. qlist sys-devel/gcc to see where files are stored, and look into toolchain.eclass for some of the voodoo behind it. sys-devel/gcc-apple might reveal some things for you as well. Also have a look at gcc-config and what it looks for to detect and switch to a gcc profile.
(In reply to comment #10) > If you want to play to try and see if you can get it sort of working, have a > look at e.g. qlist sys-devel/gcc to see where files are stored, and look into > toolchain.eclass for some of the voodoo behind it. sys-devel/gcc-apple might > reveal some things for you as well. Also have a look at gcc-config and what it > looks for to detect and switch to a gcc profile. Had an attempt at splicing a gcc ebuild with the llvm-gcc ebuild and it didn't work out very well, issues with toolchain.eclass. So I'll need to look at making "inherit toolchain" work or manually do whatever it is that toolchain.eclass does. Also just to note that this doesn't imply the task is very difficult, it's just that my lack of experience in writing ebuilds means this is mostly guesswork :) If it does turn out to be a large task, it would probably be more worthwhile to focus efforts on allowing clang to replace gcc (which would most likely be a large project) as llvm-gcc isn't heavily developed any more and Apple's decision to make llvm/clang the default compiler framework in XCode 4 will accelerate development and make clang a viable GCC replacement in the near future. Also just to note, should the clang work be seen as the best option, the only work that _should_ be needed is to create a clang gcc-config, or something similar. Canonical have indicated they intend to make clang the default compiler in the near future (even considering 2.8 as a starting point) which means lots of nice upstream code to make everything build properly.
Your tip about gcc-apple may have been a good one. It appears to do what I want, but since I'm no ebuild wizard it might take me a while to fix it for llvm-gcc. What I will also need to look at is whether or not any version of glibc builds these days, because this would be fairly pointless if it can't build a core component of the system.
llvm-gcc will be officially dropped upstream in next release in favor of clang and dragonegg, so marking this bug as WONTFIX. Hacked support for dragonegg would be possible, it "just" needs a gcc profile which loads its plugin, but first we need dragonegg in tree and a gcc that supports it (probably 4.6, need to test it)
