the llvm 3.4 build fails on darwin. also the c include directories do not include the prefix directory. Reproducible: Always
Created attachment 371572 [details, diff] fixes the build settings, and the darwin issues in the ebuild
Created attachment 371574 [details, diff] llvm fix the arm build dependency introduced in llvm 3.4 on darwin
Created attachment 371576 [details, diff] replaced epatch PN with epatch llvm in build
+ # Setup the search path to include the Prefix includes + if use prefix ; then + conf_flags+=( --with-c-include-dirs=${EPREFIX}/usr/include:/usr/include ) + fi Do you *really* need to put that inside a "use prefix" block?
(In reply to Jeremy Olexa (darkside) from comment #4) > + # Setup the search path to include the Prefix includes > + if use prefix ; then > + conf_flags+=( --with-c-include-dirs=${EPREFIX}/usr/include:/usr/include ) > + fi > > Do you *really* need to put that inside a "use prefix" block? that's how it was in clang-3.3 ebuild before it disappeared. why don't you just suggest how you think it should be done correctly?
I didn't look at the previous versions, sorry. EPREFIX will get evaluated to "" on Gentoo Linux, so there is not much value in putting it in a special prefix block, assuming we are only prepending EPREFIX to the Gentoo Linux version. Is that correct?
(In reply to Jeremy Olexa (darkside) from comment #6) > I didn't look at the previous versions, sorry. > > EPREFIX will get evaluated to "" on Gentoo Linux, so there is not much value > in putting it in a special prefix block, assuming we are only prepending > EPREFIX to the Gentoo Linux version. Is that correct? ahhh ok. i thought you had something in mind. while what you say is correct i don't think it would be a good thing to do. it will evaluate to "" that is correct, however, i don't think there is any special logic in place to check the search page contains duplicates(personally i don't see a reason why it should). so by leaving out the use prefix check we're essentially polluting the compiler search path. while theoretically nothing will happen, except that it would worst check the path if a file doesn't exist we should refrain from setting it unnecessarily. anyway, that's just my opinion.
(In reply to Jeremy Olexa (darkside) from comment #6) > I didn't look at the previous versions, sorry. I think the check got lost when clang was merged into the llvm ebuild.
Partial duplicate of bug #502318. Since this one has discussion and addresses more issues it might be best to duplicate the other way, but I'll leave that to the devs to decide.
I think this got fixed, as we now have a llvm toolchain that is able to bootstrap a system.
