Hello all! This is a follow-up to bug 88628 and bug 93908, which have been trying to provide ebuilds for the LLVM compiler infrastructure. See http://llvm.org/ Now that version 2.0 is out, I wrote and tested these two ebuilds the best I could and submit them now for further comments. There are still a few things to polish though, see the comments in the ebuilds. They expect to be in the category sys-devel, but this as well as the name 'llvm-base' (as opposed to simply 'llvm') can be argued about.
Created attachment 125709 [details] ebuild for llvm-base-2.0
Created attachment 125710 [details] Patch required for llvm-base-2.0
Created attachment 125712 [details] ebuild for llvm-gcc-2.0
*** Bug 88628 has been marked as a duplicate of this bug. ***
*** Bug 93908 has been marked as a duplicate of this bug. ***
works on ~amd64 with a small change to llvm-gcc-2.0.ebuild: --- llvm-gcc-2.0.ebuild.orig 2007-08-06 10:40:15.000000000 +0200 +++ llvm-gcc-2.0.ebuild 2007-08-06 10:44:36.000000000 +0200 @@ -87,9 +87,13 @@ # --disable-shared is to avoid this problem: # http://llvm.org/bugs/show_bug.cgi?id=896 + if useq amd64; then + EXTRA_CONF_ARGS="--disable-multilib" + fi + "${S}"/configure --prefix="${MY_LLVM_GCC_PREFIX}" --disable-shared \ --disable-nls --enable-languages=c,c++ --infodir=/usr/share/info \ - --mandir=/usr/share/man || die "./configure failed" + --mandir=/usr/share/man ${EXTRA_CONF_ARGS} || die "./configure failed" emake || die "emake failed"
There are some important issues with this ebuild. There are bunch of gcc versions which are known to be broken (they miscompiles different parts of LLVM). Typical examples are: 3.4.x with x<3 and 4.1.x on x86-32, 3.4.x and 4.1.x on x86-64. This is pretty important to warn user about broken gcc's. Many bugs were filled due to this :( I'll try to prepare updated ebuilds.
Also, patch is not needed for LLVM mainline. So, it won't be needed for nextcoming 2.1 release.
(In reply to comment #7) > There are some important issues with this ebuild. There are bunch of gcc > versions which are known to be broken Yes, it says so in the comments inside pkg_setup(), but I didn't want to bother with this yet. If you feel like completing pkg_setup() to check for the broken GCCs, that would be great. > Also, patch is not needed for LLVM mainline. So, it won't be needed for > nextcoming 2.1 release. Yes, that patch actually directly came from mainline. As an additional note: Exception handling is not working in llvm-gcc 2.0 and is disabled (all catch-blocks are simply ignored). This is said to work on mainline, but I haven't tested that yet and will be included in version 2.1, which (last time I checked) was to be expected sometime in September.
(In reply to comment #9) > (In reply to comment #7) > > There are some important issues with this ebuild. There are bunch of gcc > > versions which are known to be broken > > Yes, it says so in the comments inside pkg_setup(), but I didn't want to bother > with this yet. If you feel like completing pkg_setup() to check for the broken > GCCs, that would be great. This is pretty important. We saw some amount of bugs filled due to broken gcc versions :( > > Also, patch is not needed for LLVM mainline. So, it won't be needed for > > nextcoming 2.1 release. > > Yes, that patch actually directly came from mainline. > > As an additional note: Exception handling is not working in llvm-gcc 2.0 and is > disabled (all catch-blocks are simply ignored). This is said to work on > mainline, but I haven't tested that yet and will be included in version 2.1, > which (last time I checked) was to be expected sometime in September. Yeah. Exceptions are more or less working (I took part in its implementation, actually :) ) on llvm-gcc-4.0 and I expect them to be much more solid in new llvm-gcc-4.2 (at least some non-trivial packages passed). Both applies to x86-32/linux only :(
Created attachment 132036 [details] ebuild for llvm-base-2.1 Here are ebuilds for release 2.1 of LLVM and its GCC-4.0 front-end. Summary of changes (to ebuild) and status: - New 'alltargets' use flag to llvm-base, which builds back-ends for all targets instead of the native one. Otherwise, only minor changes to the ebuilds - It still doesn't check for broken compilers/tools. I don't currently feel like fixing this, partly also because I don't think it's worth it yet. For now I just suggest people reading this just choose the latest stable version of everything if they have problems. - IMHO, it's all still way too unstable for real use, but YMMV. (New exception handling in 2.1 didn't work as I would have wanted.) - llvm-gcc uses the gcc-4.0-based frontend. As of version 2.1, there is also a gcc-4.2-based front-end, which I haven't looked at. Maybe llvm-gcc should be renamed to llvm-gcc40 and llvm-gcc42 if it's at all possible to have trailing numbers on package names.
Created attachment 132037 [details] ebuild for llvm-gcc-2.1
Looks like Mesa's gonna use this, so the x11 team might pick it up (perhaps in collaboration with whoever ends up maintaining pypy, once that's ready). I'll try to review these ebuilds at some point.
(In reply to comment #13) > Looks like Mesa's gonna use this, so the x11 team might pick it up (perhaps in > collaboration with whoever ends up maintaining pypy, once that's ready). I'll > try to review these ebuilds at some point. > Donnie, I'm one of LLVM developers and I'm using gentoo, so I can easily maintain these ebuilds. Currently I'm looking for a way to make llvm-gcc to be slotted. Also, I have slightly updated ebuild for LLVM itself. I'll post it soon here.
(In reply to comment #14) > Donnie, I'm one of LLVM developers and I'm using gentoo, so I can easily > maintain these ebuilds. Great! > Currently I'm looking for a way to make llvm-gcc to be > slotted. Are your problems with the LLVM build system, or with getting the ebuild to do what you want? > Also, I have slightly updated ebuild for LLVM itself. I'll post it soon here. Sounds good. I just got another idea for where to put this -- we have a toolchain overlay, and that might be a decent spot to keep this up to date in an easier fashion than Bugzilla. Thoughts?
i am creating some different ebuilds that would install everything in a gentoo way. llvm installed as binutils and gcc 4.2.2 patched with the llvm patch (use llvm) you can switch to llvm with binutils-config ( i think it should be renamed to linker-config when llvm went really stable and extended to also hold linker name llvm/binutils) at the moment only the version number makes a difference. for this to work as expected i had to create/modify some eclasses toolchain-llvm.eclass (heavely modified toolchain-binutils.eclass) [1] toolchain-gcc.eclass (is the toolchain.eclass extended with llvm) [2] the llvm gcc patch still not compiles [3] you can find everything in my overlay [4] (prepared for layman) exept the gcc ebuild [5] Mario 1. https://svn.mars.arge.at/filedetails.php?repname=linamh&path=%2Ftrunk%2Flinamh%2Feclass%2Ftoolchain-llvm.eclass 2. https://svn.mars.arge.at/filedetails.php?repname=linamh&path=%2Ftrunk%2Flinamh%2Feclass%2Ftoolchain-gcc.eclass 3. http://ftp.mars.arge.at/pub/gcc-4.2.2-llvm2.1-3.patch.bz2 4. http://ftp.mars.arge.at/pub/overlay/linamh-overlay.xml 5. http://ftp.mars.arge.at/pub/gcc-4.2.2.ebuild
has anyone tested 2.2? :)
I've tried compiling llvm from linamh's overlay. In the middle of building llvm, it dies with make[2]: Entering directory `/var/tmp/portage/sys-devel/llvm-2.2/work/build/tools/llvm-dis' make[2]: *** No rule to make target `/usr/lib64/llvm/x86_64-pc-linux-gnu/2.2/libLLVMBitReader.a', needed by `/var/tmp/portage/sys-devel/llvm-2.2/work/build/Release/bin/llvm-dis'. Stop. make[2]: *** Waiting for unfinished jobs.... This actually seems to be an issue with the llvm-base ebuild (although I could easily be wrong.)
Any word on this? The overlay mentioned in comment #16 has the 2.1 ebuilds but doesn't appear to contain anything newer.
it would also appear as if llvm-2.3 has been released. I'll see what I can do in terms of getting a working ebuild in the dear future.
Created attachment 160508 [details] 2.3 with compiler checks I tried to code all compiler problems that would affect Gentoo, as well as some bison and binutils problems. It is also updated to llvm 2.3. It seems to work on my computer (amd64).
Sorry, I forgot to add "base" suffix! (I prefer it as plain "llvm" for myself)
Created attachment 160511 [details] optimization flags and PIC for 64bits (new USE) This will take care of applying the patch for PIC generation on 64 bits, in case we set the PIC flag. I chose to add a new flag since this is not an official patch and might be problematic. However it is necessary for some llvm applications, like Q programming language. Added configure flags that improve optimization, in case we don't want the debug build.
Created attachment 160513 [details] Cyrille Berger's patch for 64bits PIC
Created attachment 160515 [details] Cyrille Berger's patch for 64bits PIC Ups! Sorry, a typo...
Created attachment 160558 [details] cleaner way of doing PIC cleaner way of doing PIC One question: shouldn't we think in adding this to some overlay? What's your opinion?
Hi! AFAIK there is already another llvm-2.3 ebuild in the overlay mentioned in comment 16, but it doesn't compile for me, Álvaro's does ;-) I tried to use the attached llvm-gcc ebuild with the llvm-2.3 Álvaro's ebuild (renamed to llvm-base) with adapted version and URL but I can't compile it (some parse error in a llvm-header). Then I tried to build it manually as described on llvm home page and I get internal compiler errors. Does someone use llvm-gcc-2.3? If yes, what compiler did you use to build?
i want to get my ebuild compile but i always have error on progs not finding the libs this means there is something wrong with my patches i don't have the time to figure them out at the moment. so the overlay is now pretty useless! if you find the error it would be a greate help.
(In reply to comment #27) > Hi! > > AFAIK there is already another llvm-2.3 ebuild in the overlay mentioned in > comment 16, but it doesn't compile for me, Álvaro's does ;-) > > I tried to use the attached llvm-gcc ebuild with the llvm-2.3 Álvaro's ebuild > (renamed to llvm-base) with adapted version and URL but I can't compile it > (some parse error in a llvm-header). Then I tried to build it manually as > described on llvm home page and I get internal compiler errors. > > Does someone use llvm-gcc-2.3? If yes, what compiler did you use to build? > Hi! I'll try to make the llvm-gcc ebuild after my vacations, I'm not with my gentoo box here. That's up to 1 month, so if someone makes it would be fantastic! :) About the name: well, I don't like disturbing on previous decisions, but I prefered to have that name since llvm-base is actually LLVM. Then llvm-gcc is another project. Llvm is the name of the project, and it is not just a base, but a whole set of utilities, library and the JIT. It is rather complete by itself, especially as a development package. In the future, when clang substitutes or coexists with llvm-gcc, it will have even more sense to name it after the project's name. :-) Anyway, if you all want it named llvm-base, I'll send all future contributions with the suffix. Or, is there any reason I'm missing?
(In reply to comment #29) > About the name: well, I don't like disturbing on previous decisions No, now is exactly the right time to do that, so it's very fine you raise this concern. FWIW, when I opened this bug and posted those ebuild I only followed the convention from bug 88628, but didn't think much about the name. > but I > prefered to have that name since llvm-base is actually LLVM. Then llvm-gcc is > another project. Llvm is the name of the project, and it is not just a base, > but a whole set of utilities, library and the JIT. It is rather complete by > itself, especially as a development package. I don't agree that word "base" suggests that something is not complete and not usable by itself alone. (This word might be used in this sense in same package names, but then again, not in others.) And it's not untrue that many users will actually go on and install llvm-gcc or llvm-clang. That said, I don't see why "llvm" wouldn't be a great name for this ebuild either. I'd even prefer shortening it to "llvm", for the sole reason of removing a useless word that neither adds value to nor removes value from the name.
Just so everyone knows. I'm interested in trying this out. I haven't had a chance yet due to time constraints but when I do get around to tossing it into the tree.. I had fully intended on dropping the "base" portion of the name.
(In reply to comment #26) > Created an attachment (id=160558) [edit] > > One question: shouldn't we think in adding this to some overlay? What's your > opinion? > This ebuild still fails the multilib-check on amd64: Files matching a file type that is not allowed: usr/lib/LLVMHello.so.0.0.0 Also following QA notices should be reported upstream: * QA Notice: Pre-stripped files found: * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-as * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-stub * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-db * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-ar * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvmc2 * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-ld * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-bcanalyzer * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/bugpoint * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-ranlib * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-extract * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-nm * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-link * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llc * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/lli * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/opt * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-prof * /home/tmp/portage/sys-devel/llvm-2.3/image/usr/bin/llvm-dis
sys-apps/which is missing from DEPEND
Created attachment 163456 [details, diff] llvm-2.3-dont-build-hello.patch Fixes the multilib problem.
Created attachment 163457 [details, diff] llvm-2.3-disable-strip.patch Disables stripping of the executables, so portage can do it itself if needed.
Created attachment 165269 [details] New ebuild, incorporating patches. I tried to emerge using the attached version of the ebuild here (which basically incorporates all the patches that have been attached). But I have a few problems. First, I get this on installing: sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/c: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/c++: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/cpp: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/cxx: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/ll: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found sed: can't read /var/tmp/portage/dev-libs/llvm-2.3/image//etc/llvm/st: No such file or directory /var/tmp/portage/dev-libs/llvm-2.3/temp/environment: line 2119: sed failed: command not found What's that about? Also, I don't get a llvm-config binary. I think that should be there somehow? I'm trying to install llvm in order to be able to run llvm-py... For those who want to test this easily, I have an overlay in Mercurial: http://hg.xavamedia.nl/portage/
2.3 ebuild found in http://hg.xavamedia.nl/portage/file/413f367817fb/dev-libs/llvm/ did not work for me: if failed to make install make[3]: Entering directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/llvm' llvm[3]: Compiling llvm.mli for Release-Asserts build llvm[3]: Documenting llvm.odoc make[3]: Leaving directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/llvm' make[3]: Entering directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitreader' make[3]: Leaving directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitreader' make[3]: Entering directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitreader' make[3]: *** No rule to make target `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/Release-Asserts/lib/ocaml/llvm.cmi', needed by `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitreader/Release-Asserts/llvm_bitreader.cmi'. Stop. make[3]: Leaving directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitreader' make[3]: Entering directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitwriter' make[3]: Leaving directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitwriter' make[3]: Entering directory `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitwriter' make[3]: *** No rule to make target `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/Release-Asserts/lib/ocaml/llvm.cmi', needed by `/mnt/old/var-tmp/portage/dev-libs/llvm-2.3/work/llvm-2.3/bindings/ocaml/bitwriter/Release-Asserts/llvm_bitwriter.cmi'. Stop.
same error occurs with ebuild taken from post no. 26, attach id=160558 i planned to append emerge --info output and smth else in compressed form, but see no way of creatin attachment here. Am i too stupid to use this web page?
Created attachment 169784 [details] emerge --info and emerge log for comment no.37
the problem described in comment no. 37 does not show up when usin all-new software i will furher investigate this. Guess some dependancy >=some/prog is required
LLVM 2.4 was released a few days ago. I just tested the latest ebuild attached to this bug (the one for 2.3), and it merged fine on my ~amd64 system. The following errors occurred, but they seem to be harmless since, again, the package installed just fine afterward. * Configuring llvmc sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/c: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/c++: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/cpp: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/cxx: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/ll: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found sed: can't read /var/tmp/portage/sys-devel/llvm-2.4/image//etc/llvm/st: No such file or directory /var/tmp/portage/sys-devel/llvm-2.4/temp/environment: line 2200: sed failed: command not found >>> Completed installing llvm-2.4 into /var/tmp/portage/sys-devel/llvm-2.4/image/
I had to disable the ocaml bindings since there was an error. (A path seemed to be wrong but I could not fix it yet.) Otherwise llvm 2.4 installed fine.
(In reply to comment #41) > LLVM 2.4 was released a few days ago. I just tested the latest ebuild attached > to this bug (the one for 2.3), and it merged fine on my ~amd64 system. The > following errors occurred, but they seem to be harmless since, again, the > package installed just fine afterward. llvmc was dropped in favour of llvmc2, thus these steps are not required anymore
Created attachment 171741 [details] Ebuild for LLVM 2.4 Removed llvmc configuration stuff.
Created attachment 171745 [details] Ebuild for llvm-gcc 2.4 Adapted from the 2.1 ebuild attached to this bug, works on my system (~amd64)
is there any successful ebuild for cross-compiling llvm-gcc? i got "unhandled f32 type" when compilin for mips, see http://llvm.org/bugs/show_bug.cgi?id=3068
(In reply to comment #46) > i got "unhandled f32 type" when compilin for mips, see > http://llvm.org/bugs/show_bug.cgi?id=3068 This is expected. MIPS backend is experimental. Don't expect it to work or to produce something usable.
See http://bugs.gentoo.org/show_bug.cgi?id=249473 I can solve this changing "emake tools-only" to "emake" It seems to have to do with the "--with-llvmgccdir" option which was initially discarded with "/dev/null". On the other hand, now the PIC patch for 64bits shouldn't be applied, as it is a new release and now is a new feature of llvm 2.4
> I had to disable the ocaml bindings since there was an error. (A path seemed to > be wrong but I could not fix it yet.) Otherwise llvm 2.4 installed fine. > I had to do this as well. As another data point, if I manually run "make" on the resulting working directory, this does not happen. Also the configure script detects the presence of ocaml by default, so if ocaml is not present on the system this will not happen.
Created attachment 184065 [details] llvm-gcc-2.5.ebuild.ImAdangerousEbuild This is a DANGEROUS ebuild that try to use the toolchain.eclass used to emerge the sys-devel/gcc packages. llvm-gcc 2.5 is still based on gcc-4.2.1, so you need the old: "gcc-4.2.1-patches-1.0.tar.bz2" "gcc-4.2.1-uclibc-patches-1.0.tar.bz2" also "sys-devel/gcc/files/" need to be copied in "sys-devel/llvm-gcc" After emerge it you need to set the current compiler with "gcc-config" After that nothing will work any more as expected, be warned again
Created attachment 184068 [details] llvm-2.5.ebuild.ImDangerousTooButLess MY_LLVM_GCC_PREFIX changed to "/usr/lib", PIC is really needed for amd64 LICENSE="BSD" but IANAL, just the web told me that
(In reply to comment #51) > LICENSE="BSD" but IANAL, just the web told me that Where did it say that? LLVM is released under the University of Illinois/NCSA Open Source License. This license doesn't exist in portage (yet), which is why I put the license 'LLVM' in the ebuild originally, along with a comment explaining the situation. That comment is still in the file you just uploaded, right under the LICENSE line. Ravi Pinjala changed it from LLVM to GPL-2 in his latest upload, which is wrong too.
uhm "http://www.opensource.org/licenses/UoI-NCSA.php", I've looked quite badly ... LICENSE=${LICENSE//BSD/UoI-NCSA} BTW, emerging -e world into a chroot show that LLVM is matured a lot and can build most of the packages in portage. There is a bug http://llvm.org/bugs/show_bug.cgi?id=2853 g++: Symbol `__gxx_personality_v0' causes overflow in R_X86_64_PC32 relocation compiling .moc/release-shared/moc_qsplashscreen.cpp and I've not run the executables. /etc/make.conf LD=/usr/bin/llvm-ld CFLAGS="-O2 -march=nocona -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,--hash-style=both"
(In reply to comment #52) > Ravi Pinjala changed it from LLVM to GPL-2 in his latest upload, which is wrong > too. This is pretty common misunderstanding :) 1. LLVM itself is distributed under UIUC license, which is pretty BSD-like 2. llvm-gcc is based on apple branch of gcc 4.2.1 (actually, it seems it's the only way to take a look into apple gcc 4.2.1) and licensed under GPLv2. All LLVM-related changes to original sources are marked with "LLVM LOCAL" markers (Apple's - via 'APPLE LOCAL"). llvm-gcc being GPLv2 is linked with LLVM itself which is perfectly ok. So: - llvm ebuild should have UIUC license specified - llvm-gcc - GPLv2 Hope, this was clear enough. One might look into http://llvm.org/docs/DeveloperPolicy.html for more details.
(In reply to comment #53) > /etc/make.conf > LD=/usr/bin/llvm-ld You don't need this at all. By default llvm-gcc generates native assembler, so it's a drop-in replacement of gcc. Hopefully in 2.6 there will be transparent LTO on linux with the help of gold linker.
Created attachment 185714 [details] LLVM 2.5 ebuild Ebuild for LLVM 2.5, adapted from the 2.4 ebuild. Highlights: * Drop PIC patch, since it's apparently included upstream * Drop the PIC use flag, since it no longer requires a separate patch * Fix license * Drop most of the checks in pkg_setup in favor of blockers
Created attachment 193178 [details] An ebuild for the svn version This is a ebuild for the svn version. I had to change emake tools-only and do a normal make, as explained previously. Some people have the same problem.
I got similar errors as in #37 when trying to install the 2.5 ebuild, which seems to be caused by the OCaml bindings being broken. This can be worked around by adding --enable-bindings=none to the configure flags; maybe this could be added to the ebuild as well? (I think that bindings should be built only for those languages that are selected by USE flags anyway, so that dependencies can be set accordingly. Right now, configure seems to auto-select bindings based on whatever happens to be installed on the system, which is a bit ugly.)
Created attachment 198650 [details] Some tweaks that make it more useful for building other packages against llvm tip
I have fully working llvm installation, able to do interesting things such as converting C->C and C++->C To build a full-featured llvm from source, 3-stage process is required: 1) Build llvm base 2) Build llvm-gcc 3) Rebuild llvm base pointing it to installed version of llvm-gcc Note that step 3 is impossible with ebuilds found above in this thread, but possible with my ebuilds. What i publish here: 1) Brand new llvm-gcc ebuild, which does not bother regular gcc installation and just writes some files to /usr/lib/llvm-gcc/, and nowhere else 2) Cleaned/reorganised/improved llvm ebuild 3) This short howto (labeled a to d): ---- mini-howto start ----- a) Put 2 my ebuilds llvm-gcc-2.5-r2.ebuild and llvm-2.5-r1.ebuild into appropriate places and allow them to build b) USE="-bootstrap -alltargets" emerge =sys-devel/llvm-2.5-r1 c) emerge =sys-devel/llvm-2.5-r1.ebuild d) USE="bootstrap alltargets" emerge =sys-devel/llvm-2.5-r1 ---- mini-howto end -------------- Some problems: QA warnings, bad links in html, bad man pages installed by llvm-gcc, C++ code converted for C does not compile I really don't mind if someone addresses the problems, or bugreport upstream. I further suggest that llvm base be installed not in /usr/ but in /usr/lib/llvm-base/. And how to properly install and allow easy access to multiple versions of llvm toolchain? And how to ebuild some useful software such as tamp, lzma and p7zip with llvm?
Created attachment 201594 [details] new environment-friendly llvm-gcc ebuild, sys-devel/llvm-gcc-2.5-r2.ebuild
Created attachment 201603 [details] llvm base ebuild, sys-devel/llvm-2.5-r1.ebuild
correction for mini-howo: c) should read c) emerge =sys-devel/llvm-gcc-2.5-r2
Comment on attachment 201594 [details] new environment-friendly llvm-gcc ebuild, sys-devel/llvm-gcc-2.5-r2.ebuild # Copyright 1999-2009 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: # ebuild submitted by gentoo user mehrunes 18 aug 2009 inherit eutils toolchain-funcs DESCRIPTION="Low Level Virtual Machine" HOMEPAGE="http://llvm.org/" SRC_URI="http://llvm.org/releases/$PV/$PN-$PV.tar.gz" LICENSE="LLVM" # most part of LLVM fall under the "University of Illinois Open Source License" # which doesn't seem to exist in portage yet, so I call it 'LLVM' for now. it # can be read from llvm/LICENSE.TXT in the source tarball. # the directory llvm/runtime/GCCLibraries/libc contains a stripped down C # library licensed under the LGPL 2.1 with some third party copyrights, see the # two LICENCE* files in that directory. Those parts do *not* get built, so # we omit LGPL in ${LICENCE} SLOT="0" KEYWORDS="~amd64 ~ppc ~x86" IUSE="debug pic bootstrap alltargets" # 'jit' is not a flag anymore. at least on x86, disabling it saves nothing # at all, so having it always enabled for platforms that support it is fine # we're not mirrored, fetch from homepage RESTRICT="mirror" DEPEND="dev-lang/perl >=sys-devel/make-3.79 >=sys-devel/flex-2.5.4 >=sys-devel/bison-1.28 >=sys-devel/gcc-3.0 >=sys-devel/binutils-2.18 " RDEPEND="dev-lang/perl" PDEPEND="" S="$WORKDIR/$PN-$PV" pkg_setup() { broken_gcc=( 3.2.2 3.2.3 3.3.2 4.1.1 ) broken_gcc_x86=( 3.4.0 3.4.2 ) broken_gcc_amd64=( 3.4.6 ) gcc_vers=`gcc-fullversion` for version in ${broken_gcc[@]} do if [ "$gcc_vers" = "$version" ]; then elog "Your version of gcc is known to miscompile llvm" elog "check http://www.llvm.org/docs/GettingStarted.html for \ possible solutions" die "Your version of gcc is known to miscompile llvm" fi done if use x86; then for version in ${broken_gcc_x86[@]} do if [ "$gcc_vers" = "$version" ]; then elog "Your version of gcc is known to miscompile llvm in x86 \ architectures" elog "check http://www.llvm.org/docs/GettingStarted.html for \ possible solutions" die "Your version of gcc is known to miscompile llvm" fi done fi if use amd64; then for version in ${broken_gcc_amd64[@]} do if [ "$gcc_vers" = "$version" ]; then elog "Your version of gcc is known to miscompile llvm in amd64 \ architectures" elog "check http://www.llvm.org/docs/GettingStarted.html for \ possible solutions" die "Your version of gcc is known to miscompile llvm" fi done fi broken_bison=( 1.85 1.875 ) for version in ${broken_bison[@]} do if [ $(bison --version | head -n1 | cut -f4 -d" ") = "$version" ]; then elog "Your version of Bison is known not to work with llvm, please \ upgrade to a newer version" die "Your version of Bison is known not to work with llvm" fi done } src_compile() { # unfortunately ./configure won't listen to --mandir and the-like, so take # care of this. einfo "Fixing install dirs" sed -e 's,^PROJ_docsdir.*,PROJ_docsdir := $(DESTDIR)$(PROJ_prefix)/share/doc/'${PF}, \ -e 's,^PROJ_etcdir.*,PROJ_etcdir := $(DESTDIR)/etc/llvm,' \ -i Makefile.config.in || die "sed failed" # fix gccld and gccas, which would otherwise point to the build directory einfo "Fixing gccld and gccas" sed -e 's,^TOOLDIR.*,TOOLDIR=/usr/bin,' \ -i tools/gccld/gccld.sh tools/gccas/gccas.sh || die "sed failed" # all binaries get rpath'd to a dir in the temporary tree that doesn't # contain libraries anyway; can safely remove those to avoid QA warnings # (the exception would be if we build shared libraries, which we don't) einfo "Fixing rpath" sed -e 's,-rpath \$(ToolDir),,g' -i Makefile.rules || die "sed failed" epatch "${FILESDIR}"/llvm-2.3-dont-build-hello.patch epatch "${FILESDIR}"/llvm-2.3-disable-strip.patch local CONF_FLAGS="" if use debug; then CONF_FLAGS="${CONF_FLAGS} --disable-optimized" einfo "Note: Compiling LLVM in debug mode will create huge and slow binaries" # ...and you probably shouldn't use tmpfs, unless it can hold 900MB else CONF_FLAGS="${CONF_FLAGS} --enable-optimized --disable-assertions \ --disable-expensive-checks" fi if use alltargets; then CONF_FLAGS="${CONF_FLAGS} --enable-targets=all" else CONF_FLAGS="${CONF_FLAGS} --enable-targets=host-only" fi if use amd64 || use pic; then CONF_FLAGS="${CONF_FLAGS} --enable-pic" fi # things would be built differently depending on whether llvm-gcc is already # present on the system or not. When not bootstapping we make sure that no # llvm-gcc found local LLVM_GCC_DIR=/dev/null local LLVM_GCC_DRIVER=nope ; local LLVM_GPP_DRIVER=nope use bootstrap && { # when bootstappin, make sure configure will find installed llvm-gcc [ -z "$LLVM_GCC_PREFIX" ] && { local here=/usr/$(get_libdir)/llvm-gcc/ local LLVM_GCC_PREFIX=${here}$(ls $here | head -1) } [ -z "$(ls $LLVM_GCC_PREFIX/bin/*-gcc)" ] && die "failed to find installed llvm-gcc, LLVM_GCC_PREFIX=$LLVM_GCC_PREFIX" LLVM_GCC_DRIVER=$( ls $LLVM_GCC_PREFIX/bin/*-gcc |head -1|xargs basename ) LLVM_GCC_DIR=$LLVM_GCC_PREFIX [ -z $LLVM_GCC_DRIVER ] && die \ "failed to find installed llvm-gcc, LLVM_GCC_PREFIX=$LLVM_GCC_PREFIX" einfo "using $LLVM_GCC_DRIVER residing in $LLVM_GCC_DIR" LLVM_GPP_DRIVER=${LLVM_GCC_DRIVER/%-gcc/-g++} } CONF_FLAGS="${CONF_FLAGS} \ --with-llvmgccdir=$LLVM_GCC_DIR --with-llvmgcc=$LLVM_GCC_DRIVER \ --with-llvmgxx=$LLVM_GPP_DRIVER" econf ${CONF_FLAGS} || die "econf failed" emake || die "emake failed" } src_install() { make DESTDIR="$D" install || die "make install failed" einfo "LLVM base is distributed under University of Illinois Open Source" einfo "License, for details see doc/LICENSE.TXT" dodoc $S/LICENSE.TXT # don't install html.tar.gz in /usr/share/doc einfo "Removing archived html documentation" rm "$D"/usr/share/doc/$PF/*tar.gz || die "no such file $D/usr/share/doc/$PF/*tar.gz" # tblgen does not get installed, so remove their man pages. # llvmgcc.1 and llvmgxx.1 are present here for unknown reasons. But, since # llvm-gcc installs bad man pages, keep the 2 files alive einfo "Removing unnecessary man page" rm "${D}"/usr/share/man/man1/tblgen.1 }
Comment on attachment 201594 [details] new environment-friendly llvm-gcc ebuild, sys-devel/llvm-gcc-2.5-r2.ebuild # Copyright 1999-2009 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: # ebuild submitted by gentoo user mehrunes 18 aug 2009 LLVM_GCC_VERSION_NO=4.2 GCC_LANG="c,c++" TARGETOPTIONS="" LLVM_GCC_VERSION=$LLVM_GCC_VERSION_NO-$PV PROGRAM_PREFIX=$PN-$LLVM_GCC_VERSION #gcc installs itself under usr/lib/gcc, we go to usr/lib/$PN MY_LLVM_GCC_PREFIX=usr/$(get_libdir)/$PN/$LLVM_GCC_VERSION BUILDOPTIONS="LLVM_VERSION_INFO=$LLVM_GCC_VERSION" SRC_URI="http://llvm.org/releases/$PV/$PN-$LLVM_GCC_VERSION.source.tar.gz" DESCRIPTION="C and C++ compiler from llvm.org" LICENSE="GPL-2" KEYWORDS="~amd64 ~x86" SLOT=0 IUSE="nls" # we're not mirrored, fetch from homepage #RESTRICT="mirror" RDEPEND=" >=sys-devel/llvm-$PV" DEPEND="${RDEPEND} test? ( sys-devel/autogen dev-util/dejagnu ) >=sys-apps/texinfo-4.2-r4 >=sys-devel/bison-1.875 >=${CATEGORY}/binutils-2.18" #test dependancy is here, but testing is not implemented S="${WORKDIR}/llvm-gcc$LLVM_GCC_VERSION.source" src_compile() { cd $WORKDIR #we keep the directory structure suggested by README.LLVM, # replacing install directory with our $D/$MY_LLVM_GCC_PREFIX mkdir -p obj $D/$MY_LLVM_GCC_PREFIX cd obj $S/configure --prefix=/$MY_LLVM_GCC_PREFIX \ --program-prefix=$PROGRAM_PREFIX- \ --enable-llvm=/usr --enable-languages=$GCC_LANG \ $TARGET_OPTIONS || die "configure failed" emake $BUILDOPTIONS || die "emake failed" } clean_locale() { z=$MY_LLVM_GCC_PREFIX/share/locale einfo not installin $z ls -l $D/$z rm -rf -- $D/$z } src_install() { cd $WORKDIR/obj || die DESTDIR=$D make install || die #need no licence or fundin files, licences are kept separately man7=$MY_LLVM_GCC_PREFIX/man.man7 einfo gettin rid of $man7 ls -l $D/$man7 rm -rf -- $D/$man7 use nls || clean_locale }
i corrected some errors in my ebuilds and tried to replace existing attachments. This resulted in posts no. 64 and 65. Sorry for the long posts. post no. 64: corrected llvm-2.5-r1.ebuild post no. 65: corrected llvm-gcc-2.5-r2.ebuild
Why didn't you just *attach* the ebuilds? Or attach a diff, that's even shorter...
Created attachment 201739 [details] the 2 ebuilds, and mini howto, ebuilds now with correct indentatiom ... and inheriting necessary eclasses since there is no way of discarding erroneous posts or attachments here, i will publish my ebuilds elsewhere (most probably at my page gpu-compress.googlecode.com)
Agreed, a diff would have been much more useful. Also, I was sad to see that you brought back the broken gcc/bison version checks - IMO, it's a lot cleaner to do that with dependencies. For the curious: --- llvm-ebuild-attachment 2009 [details]-08-19 13:22:01.359383169 -0500 +++ llvm-ebuild-comment 2009-08-19 13:26:20.128337600 -0500 @@ -143,18 +143,26 @@ # things would be built differently depending on whether llvm-gcc is already # present on the system or not. When not bootstapping we make sure that no # llvm-gcc found - LLVM_GCC_DIR=/dev/null ; LLVM_GCC_DRIVER=nope + local LLVM_GCC_DIR=/dev/null + local LLVM_GCC_DRIVER=nope ; local LLVM_GPP_DRIVER=nope use bootstrap && { # when bootstappin, make sure configure will find installed llvm-gcc - [ -z "$LLVM_GCC_PREFIX" ] && - LLVM_GCC_PREFIX=/usr/lib/llvm-gcc/$(ls /usr/lib/llvm-gcc|head -1) - [ -z $(ls $LLVM_GCC_PREFIX/bin/*-gcc) ] && + [ -z "$LLVM_GCC_PREFIX" ] && { + local here=/usr/$(get_libdir)/llvm-gcc/ + local LLVM_GCC_PREFIX=${here}$(ls $here | head -1) + } + [ -z "$(ls $LLVM_GCC_PREFIX/bin/*-gcc)" ] && die "failed to find installed llvm-gcc, LLVM_GCC_PREFIX=$LLVM_GCC_PREFIX" - LLVM_GCC_DRIVER=$( ls $LLVM_GCC_DIR/bin/*-gcc | basename ) + LLVM_GCC_DRIVER=$( ls $LLVM_GCC_PREFIX/bin/*-gcc |head -1|xargs basename ) + LLVM_GCC_DIR=$LLVM_GCC_PREFIX + [ -z $LLVM_GCC_DRIVER ] && die \ + "failed to find installed llvm-gcc, LLVM_GCC_PREFIX=$LLVM_GCC_PREFIX" einfo "using $LLVM_GCC_DRIVER residing in $LLVM_GCC_DIR" + LLVM_GPP_DRIVER=${LLVM_GCC_DRIVER/%-gcc/-g++} } CONF_FLAGS="${CONF_FLAGS} \ - --with-llvmgccdir=$LLVM_GCC_DIR --with-llvmgcc=$LLVM_GCC_DRIVER" + --with-llvmgccdir=$LLVM_GCC_DIR --with-llvmgcc=$LLVM_GCC_DRIVER \ + --with-llvmgxx=$LLVM_GPP_DRIVER" econf ${CONF_FLAGS} || die "econf failed" emake || die "emake failed" --- llvm-gcc-ebuild-attachment 2009 [details]-08-19 13:31:31.765337250 -0500 +++ llvm-gcc-ebuild-comment 2009-08-19 13:31:15.200337390 -0500 @@ -10,7 +10,7 @@ LLVM_GCC_VERSION=$LLVM_GCC_VERSION_NO-$PV PROGRAM_PREFIX=$PN-$LLVM_GCC_VERSION #gcc installs itself under usr/lib/gcc, we go to usr/lib/$PN -MY_LLVM_GCC_PREFIX=usr/lib/$PN/$LLVM_GCC_VERSION +MY_LLVM_GCC_PREFIX=usr/$(get_libdir)/$PN/$LLVM_GCC_VERSION BUILDOPTIONS="LLVM_VERSION_INFO=$LLVM_GCC_VERSION" SRC_URI="http://llvm.org/releases/$PV/$PN-$LLVM_GCC_VERSION.source.tar.gz"
configure: creating ./config.status config.status: creating Makefile.common config.status: executing setup commands config.status: executing Makefile commands config.status: executing lib/Makefile commands config.status: executing lib/sample/Makefile commands config.status: executing tools/Makefile commands config.status: executing tools/sample/Makefile commands make make[1]: Entering directory `/var/tmp/paludis/sys-devel-llvm-2.5-r1/work/llvm-2.5/lib/System' llvm[1]: Compiling Alarm.cpp for Release-Asserts build llvm[1]: Compiling Disassembler.cpp for Release-Asserts build llvm[1]: Compiling DynamicLibrary.cpp for Release-Asserts build llvm[1]: Compiling Host.cpp for Release-Asserts build llvm[1]: Compiling IncludeFile.cpp for Release-Asserts build llvm[1]: Compiling Memory.cpp for Release-Asserts build llvm[1]: Compiling Mutex.cpp for Release-Asserts build llvm[1]: Compiling Path.cpp for Release-Asserts build llvm[1]: Compiling Process.cpp for Release-Asserts build llvm[1]: Compiling Program.cpp for Release-Asserts build llvm[1]: Compiling Signals.cpp for Release-Asserts build In file included from Signals.cpp:31: Unix/Signals.inc: In function 'void<unnamed>::PrintStackTrace()': Unix/Signals.inc:81: error: invalid conversion from 'const char*' to 'char*' Unix/Signals.inc:96: error: invalid conversion from 'const char*' to 'char*' make[1]: Leaving directory `/var/tmp/paludis/sys-devel-llvm-2.5-r1/work/llvm-2.5/lib/System' make[1]: *** [/var/tmp/paludis/sys-devel-llvm-2.5-r1/work/llvm-2.5/lib/System/Release-Asserts/Signals.o] Error 1 make: *** [all] Error 1 /usr/libexec/paludis/utils/emake: emake returned error 2 !!! ERROR in sys-devel/llvm-2.5-r1: !!! In src_compile at line 3686 !!! emake failed !!! Call stack: !!! * src_compile (/var/tmp/paludis/sys-devel-llvm-2.5-r1/temp/loadsaveenv:3686) !!! * ebuild_f_compile (/usr/libexec/paludis/0/src_compile.bash:51) !!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:575) !!! * main (/usr/libexec/paludis/ebuild.bash:591) diefunc: making ebuild PID 28759 exit with error die trap: exiting with error. gcc 4.4.1
Ok. Simply patch will work (I hope). When I collect the all changes I'll post a patch.
Created attachment 202564 [details, diff] llvm-2.5-gcc-4.4.patch Patch allowing llvm to be compiled by gcc 4.4.
LLVM 2.6 will be released pretty soon. So, if possible, I'd suggest you to test 2.6 prerelease stuff, so if any problems would be detected - they will be included into the release. The tarballs are available at http://llvm.org/prereleases/2.6/
(In reply to comment #73) > LLVM 2.6 will be released pretty soon. So, if possible, I'd suggest you to test > 2.6 prerelease stuff, so if any problems would be detected - they will be > included into the release. I should not type too fast: "fixes for them will be included".
What are the reasons of non-including it into portage? PS. As far as ebuilds are concerned - why bootstrap flag should be enabled during second emerge not first one (and disabled afterwards)?
do I understand correctly that you can bootstrap llvm with normal gcc?
Yeah, both llvm and llvm-gcc build fine with most GCC versions.
I would love to see this in portage.
Created attachment 203064 [details] revised llvm-2.5-r1 ebuild made compliant to Gentoo style Ok, so what is the idea behind llvm and llvm-gcc here? is that llvm-base vs llvm-gcc (being two separate packages). - indenting by 1 space is horrible - not indenting is even more horrible - setting S to WORKDIR/P is pointless - restricting mirror is only necessary if the tar may not be mirrorred or something - preferably use $(...) construct instead of `...` - broken tools detection: do it in the dependencies! no need to have portage die while it could possibly resolve some better solution - don't need to explicitly point out licence, that's what LICENSE=bla is for - how about a USE-flag doc for installing the html documentation? I went through llvm-2.5-r1.ebuild alone, result attached.
Yeah, llvm and llvm-gcc are two separate packages upstream, and the gcc frontend is much bigger than the backend, so there are definitely cases where people would just want llvm but not llvm-gcc.
Created attachment 204168 [details] llvm-2.6_pre.ebuild Ebuild for prerelease with a few changes: * EAPI2 for src_prepare * Fix again rpath cleaning * Disable stripping via KEEP_SYMBOLS * Cleaned llvm-gcc detection, enabled if llvm-gcc is installed (are there good reasons not to use llvm-gcc if it's available?) To add it to portage, I'd still like these things fixed: * multilib-strict failure: libs install in /usr/lib, not /usr/usr/lib64 * test does not work: can not find runpath(dejagnu)
OK solved the last problems remaining in llvm, so I will add llvm, llvm-gcc and clang (although I'm more intersted in clang and its static analyzer than llvm-gcc) when 2.6 final is released
Current ebuild in the portage tree fails to build for me: llvm[1]: Packaging ocamldoc documentation /bin/tar: ocamldoc: Cannot stat: No such file or directory /bin/tar: Error exit delayed from previous errors make[1]: *** [/var/tmp/portage/sys-devel/llvm-2.6_pre2/work/llvm-2.6/docs/ocamldoc.tar.gz] Error 2 Here I post the emerge --info: ================================================================= Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.30-gentoo-r4 x86_64) ================================================================= System uname: Linux-2.6.30-gentoo-r4-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4200+-with-gentoo-1.12.11.1 Timestamp of tree: Wed, 07 Oct 2009 09:30:01 +0000 app-shells/bash: 4.0_p28 dev-java/java-config: 2.1.8-r1 dev-lang/python: 2.6.2-r1 dev-util/cmake: 2.6.4 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -mtune=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=native -mtune=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ " LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="en en_US es es_ES" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/sunrise /usr/local/portage/layman/java-overlay /usr/local/portage/layman/d /usr/local/portage/manual" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aac aalib acl acpi alsa amd64 apm bash-completion berkdb bzip2 cairo cli cracklib crypt cscope cups curl d dbus dri encode ffmpeg flac fortran gcj gdbm gif glut gpm hal iconv ipv6 isdnlog jpeg jpeg2k lcms mmx modules mp3 mudflap multilib ncurses nls nptl nptlonly offensive openal opengl openmp pam pcre pdf perl png ppds pppd python qt4 quicktime readline reflection session slang spell spl sse sse2 sse3 ssl svg sysfs tcpd theora threads tiff truetype unicode v4l v4l2 vim-syntax vorbis x264 xcb xft xml xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US es es_ES" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Indeed, I forgot the ocaml comments in this (lengthy) bug. Updated version committed, it should really fix all these generated .tar.gz in docs, and adds a ocaml USE flag to fix the automagic dependency on ocaml Thanks for testing it!
llvm-2.6 and llvm-gcc-2.6 are now in tree and out of package.mask, thanks everyone in this bug!
