I'v done a rewrite for the ebuild trying to remove the old cruft.. .. and putting new cruft in (basically because Mozilla's build system swaps HOST and BUILD meaning in their configure system) However, - multilib is working well, based on inheritance of multilib-minimal - ldconfig does not complain anymore, since version magic is attached to libs - tc-is-cross-compiler detects user config and encapsulates CROSS_COMPILE related stuff - swapping CHOST and CBUILD (needed, since econf assumes --host=${CHOST}) is handled gracefully with the help of some locals in multilib_src_configure - improper src / build separation is worked around by using multilib_copy_sources in src_prepare - 64bit detection is done by checking either - multilib get-libdir (every imaginable 64bit compile does put libs in "lib64" for now) or - the end of the first string of ${CTARGET:-${CHOST}} triple (if multilib isn't used or bypassed) - running a semi-configure to check the resulting binary might fail and - file (the program) might not work correctly - the output of file may change - file is not in Tools Reference of ebuild guide - file can't detect bitcode objects as produced by llvm/clang (not native code) I've tested single and multilib building thoroughly for x86/amd64, but (non-multilib) cross-compilation needs testing. Thx for reviewing. Reproducible: Always
Created attachment 345602 [details, diff] nspr-4.9.6.ebuild.patch diff to current ebuild
Created attachment 345604 [details] nspr-4.9.6-r1.ebuild whole ebuild
(In reply to comment #0) > - running a semi-configure to check the resulting binary might fail and > - file (the program) might not work correctly > - the output of file may change > - file is not in Tools Reference of ebuild guide > - file can't detect bitcode objects as produced by llvm/clang (not native > code) Note: The current TRY_COMPILE in the ebuild's src_configure works well, if used with gcc, clang -O2 and should work with everything that outputs ELF objects recognized by 'file'. clang -O4 does not work, the error you will get stems from the ebuild: >>> Starting src_configure !!! ERROR in dev-libs/nspr-4.9.6::gentoo: !!! In src_configure at line 4611 !!! Failed to detect whether your arch is 64bits or 32bits, disable distcc if you're using it, please The overhauled ebuild does finish using clang -O4, because the optimization flag does not end up in the compile string for the source, it is replaced by mozilla's default (-O2), i.e. the only reason the stock portage ebuild above was failing was the need to produce an object file in src_configure.. ..and the flag filtering for this test compile was not done in the same way as code econf/emake filters flags. I've not tried actually forcing -O4 on the production code with optimize, so I do not know whether an LTO build succeeds. Greetings
(In reply to comment #3) > I've not tried actually forcing -O4 on the production code with optimize, so > I do not know whether an LTO build succeeds. clang -O2 and -O4 builds fine, but only doing the DEFAULT_ABI=amd64, using both ABIs, x86 and amd64, the build fail, regardless of optimization level. Here is the output for x86 ABI using clang -O2 >>> Starting src_compile * x86: running multilib-minimal_abi_src_compile make -j1 -C build make: Entering directory `/var/tmp/paludis/dev-libs-nspr-4.9.6-r1/work/nspr-4.9.6-x86/build' make -C config export make[1]: Entering directory `/var/tmp/paludis/dev-libs-nspr-4.9.6-r1/work/nspr-4.9.6-x86/build/config' clang -m32 -o now.o -c -march=native -pipe -O4 -Wall -pthread -O2 -fPIC -UDEBUG -DNDEBUG=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1 -D_GNU_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1 -Di386=1 -DHAVE_DLADDR=1 -DHAVE_LCHOWN=1 -DHAVE_SETPRIORITY=1 -DHAVE_STRERROR=1 -DHAVE_SYSCALL=1 -D_REENTRANT=1 -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM ../../mozilla/nsprpub/config/now.c clang -m32 now.o -march=native -pipe -O4 -Wall -pthread -O2 -march=native -pipe -O4 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -Wl,-z,norelro -o now /usr/bin/x86_64-pc-linux-gnu-ld: error: lto-llvm.o-gfNKkS: incompatible target clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [now] Error 1 make[1]: Leaving directory `/var/tmp/paludis/dev-libs-nspr-4.9.6-r1/work/nspr-4.9.6-x86/build/config' make: *** [export] Error 2 make: Leaving directory `/var/tmp/paludis/dev-libs-nspr-4.9.6-r1/work/nspr-4.9.6-x86/build' I will not pursue this error further, since I do not need the library to this extend. As a rule of thumb: - if both ABIs are needed, GCC can be used, with or w/o LTO - if just the DEFAULT_ABI is needed, CLANG compiles it with or w/o LTO -> but it did not for x86 ABI, clang -m32 in my case With unpatched ebuild only the DEFAULT_ABI works, with gcc+lto or clang-no-lto.
(In reply to comment #4) > -> but it did not for x86 ABI, clang -m32 in my case clarification: that is if x86 is not the DEFAULT_ABI, e.g. built on amd64 multilib If DEFAULT_ABI=x86 and clang targets x86 as a default, the ebuild works just the way a DEFAULT_ABI=amd64 would and does ok.
Created attachment 345706 [details, diff] nspr-4.9.6.ebuild.patch add + # respect optimization flags + local OPT=$(get-flag -O?) + filter-flags -O? and + $(use_enable !debug optimize ${OPT})
Created attachment 345708 [details] dev-libs/nspr/nspr-4.9.6-r1.ebuild
Please attach the entire build log to this bug report.
Created attachment 345918 [details] build log (nspr-4.9.6.ebuild, clang -O4) 1366307711-install-dev-libs_nspr-4.9.6:0::gentoo.out
(In reply to comment #9) > Created attachment 345918 [details] > build log (nspr-4.9.6.ebuild, clang -O4) > 1366307711-install-dev-libs_nspr-4.9.6:0::gentoo.out the patch addresses other issues as well (multilib, optimization flags), their nature is more an enhancement, hence no build log portraying errors for them..
Created attachment 366188 [details, diff] nspr-4.10.2.patch I've updates your changes against latest nspr version in tree. It also creates symlinks of the so files (portage was complaining about it) and adds blocks against the emul-packages. It still works on multilib-amd64/x86. Though, i couldn't test cross compilation... BTW, this bug should block bug 454644 :)
I've redone an ebuild and committed it (p.masked) to the tree today, nspr-4.16-r1 , please test. Note that emul-linux-x86-baselibs has not been adjusted yet; mgorny will be doing that shortly however (20140508-r10 is the target i believe)
I've cleaned up nspr a bit more (like added x86|... to the ABI conditionals so that all known 32-bit arches won't cause the fallback to be used :)), and committed the emul-linux. Both are now p.masked in the main multilib mask for further testing.
nspr-4.10.10-r1 builds with clang 3.5.0 on my machine.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
