Matt has asked on the IRC if we could add multilib support to the llvm ebuild; i.e. building 32-bit version as well on amd64. If we did that, mesa would do the same benefiting multilib users who currently undergo breakage due to constantly outdated emul-linux packages. The first thing that worries me about it is the compilation time. LLVM is complex enough to take long to compile even on my distcc. If we switched to multilib, the time would practically double. Consider the fact that sometimes 40 minutes vs 80 minutes is important enough to have to abort the compilation; and that the possibilities of random failure increase geometrically (like lack of free space in build dir, ICE of overheating and so on). Thus, not having anything like dynamic SLOTs, I would rather go with maintaining two copies of the same ebuild (it's as simple as remembering about both!), possibly in a dedicated multilib category. What do you think?
Ok, since cmake build is unlikely to be useful anytime soon, I think we should proceed with hacking the existing ebuild. My suggestion is to rename 32-bit llvm-config to llvm-config32 (or llvm-config-${ABI}?), and just modify mesa to use that. I believe introducing the whole wrapper magic for a single executable is not really worth it. voyageur, what do you think?
Sounds like a good plan! 3.3 (and probably later versions) will still use autotools, so if this works fine for multilib mesa, let's go for it
(In reply to Michał Górny from comment #1) > Ok, since cmake build is unlikely to be useful anytime soon, I think we > should proceed with hacking the existing ebuild. > > My suggestion is to rename 32-bit llvm-config to llvm-config32 (or > llvm-config-${ABI}?), and just modify mesa to use that. I believe > introducing the whole wrapper magic for a single executable is not really > worth it. > > voyageur, what do you think? uhm, yet again? Please stop making random changes to ebuilds forcing other ebuilds to be adjusted downstream to work with your custom changes. We already have a working and long-term tested wrapper solution in the multilib-portage overlay, we even have a bash and a native version in there. So please dont start again with random hacks (remember, that it failed for your random header hacks too?) and do it properly without requesting other packages to do manual additional changes, which cannot be sent upstream. In short: use wrapper || dont do multilib for the binaries
Don't start this again.
There's an initial multilib version of llvm+clang in ::mgorny. It needs a lot of testing and probably some love wrt tests. I think they fail now for x86 but I spent too much time rebuilding LLVM today to address it :). A few notes: 1. llvm-config is renamed to llvm-config.${ABI} for non-native ABIs, 2. with USE=test, full 32-bit llvm is built (but not installed). without uSE=test, only llvm libraries are built. 3. building clang libraries separately is broken, so full clang is always built for non-native ABIs. 4. i've removed the patches moving /usr/lib/clang to /usr/lib64/clang. it's a similar case to gcc, with the directory containing arch-agnostic headers and clang_rt libraries which are reused by both variants. yet, for some reason, clang seems to still be looking for it in /usr/lib64. patch appreciated. Feedback and improvements for build process will be appreciated.
I've tested your llvm ebuild in a virtual maschine with and without clang. (package details below). It builds fine :) Anything else i could test which might help you? If it helps i could also set up an x86 environment (vm) and try to build it with "test" enabled. emerge -pv llvm These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R *] sys-devel/llvm-9999-r1::mgorny USE="libffi static-analyzer -clang* -debug -doc -gold -multitarget -ocaml -python {-test} -udis86 -vim-syntax" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 -pypy1_9 -pypy2_0 -python2_5 -python2_6" VIDEO_CARDS="-radeon" 0 kB
Thanks. It might be also useful to test with USE=debug since AFAICS that changes some paths within build tree and some random stuff like PaX marking may fail.
I've just committed llvm-3.3-r1 and clang-3.3-r100 to my overlay. I'd appreciate testing that version more thoroughly and, if voyageur agrees, I'd like to commit it p.masked along with 9999-r1. Do you feel like I should backport the changes to older versions as well?
Created attachment 353666 [details] build.log 3.3-r1 fails to build with debug (and "test" enabled). I've attached the build.log. USE="debug" emerge -pv1 =sys-devel/llvm-3.3-r1 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD~] sys-devel/llvm-3.3-r1::mgorny [9999-r1::mgorny] USE="debug* libffi static-analyzer {test} -clang* -doc -gold -multitarget -ocaml -python -udis86 -vim-syntax" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 -pypy1_9 -pypy2_0 -python2_5 -python2_6" VIDEO_CARDS="-radeon" 0 kB
(In reply to Michael Mair-Keimberger (iamnr3) from comment #9) > Created attachment 353666 [details] > build.log Please don't upload .tar.gz.gz. A simple gzipped log would be enough, and unpacking such a thing is near to insane handwork (including guessing what's wrong with it). And I'm afraid I can't really think about your issue right now. The current version may be semi-broken, and I'll start testing it over again when I fix all the issues so far.
Fixed in -3.3-r1 and -9999.
I've rebased mesa-9999-r51 against these ebuilds In my multilib llvm I had llvm-config-amd64 and llvm-config-x86 with llvm-config being a symlink to the native one It would be great if you could use that behaviour again (event with the . rather than the -) as it makes it simpler to select the correct one in the ebuild
