Libreoffice is reported to compile successfully with clang: https://wiki.documentfoundation.org/Development/Building_LibreOffice_with_Clang. I've checked this myself and indeed it works. Please change gcc version check in ebuild. fads@extensa ~ % cat /etc/portage/package.env | grep libreoffice app-office/libreoffice clang fads@extensa ~ % cat /etc/portage/env/clang CC="clang" CXX="clang++" AR="ar" LD="ld" CFLAGS="-O2 -pipe -march=core2" CXXFLAGS="${CFLAGS}" fads@extensa ~ % clang -v clang version 3.2 (tags/RELEASE_32/final) Target: x86_64-pc-linux-gnu Thread model: posix fads@extensa ~ % libreoffice --version LibreOffice 4.0.2.0 fads@extensa ~ % equery l -o libreoffice * Searching for libreoffice ... [--O] [ ] app-office/libreoffice-4.0.0.3-r1:0 [I-O] [ ] app-office/libreoffice-4.0.9999:0 Reproducible: Always
Yes the libreoffice build with clang, but have few issues on runtime. Even the clang compiler in tinderboxes is opensuse and gentoo :-) Anyway if you want it supported by ebuild just write proper patch for the phase call.
Created attachment 347584 [details] suggested patch for ebuild This adds a user-settable variable (CHECK_ME_HARDER) to skip checking (and failing) in pkg_pretend. Checks are skipped if the variable is set to "no". I suggest setting this on a per-package basis in /etc/portage/env/ (see portage(5)). I have tested, and the ebuild still checks and dies if the variable is unset, where as if it's set to "no" the package build system is launched. I have not tested that libreoffice builds or works reasonably afterwards.
Sorry, I missed an important aspect above. Unfortunately, kde4-base.eclass also has a similar checks, which dies any ebuild that inherits it if kde4-base_pkg_setup() is called. This checking seems wrong, on the assumption this function might be called by an ebuild that does not (or only optionally does) build kde-based applications. I suggest this can be solved by either duplicating the required parts of kde4-base_pkg_setup() in the libreoffice ebuild, or introducing a way to skip the dieing in kde4-base.eclass (similar to my ebuild patch above).
Comment on attachment 347584 [details] suggested patch for ebuild This still affects libreoffice-4.1.0.1 . Here is a refined version of the refined ebuild patch, using an already established variable to disable the incorrect functionality while preserving the warning output. --- a/app-office/libreoffice/libreoffice-4.1.0.1.ebuild +++ b/app-office/libreoffice/libreoffice-4.1.0.1.ebuild @@ -256,7 +256,7 @@ pkg_pretend() { ( [[ $(gcc-major-version) -eq 4 && $(gcc-minor-version) -lt 6 ]] ) \ ; then eerror "Compilation with gcc older than 4.6 is not supported" - die "Too old gcc found." + [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]] && die "Too old gcc found." fi fi @@ -273,7 +273,11 @@ pkg_pretend() { pkg_setup() { java-pkg-opt-2_pkg_setup - kde4-base_pkg_setup + if [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]]; then + kde4-base_pkg_setup + else + nonfatal kde4-base_pkg_setup + fi python-single-r1_pkg_setup [[ ${MERGE_TYPE} != binary ]] && check-reqs_pkg_setup
I would rather have this sorted properly in the eclass and then here. Something like checking value of CC to see if it is clang or gcc and determine the checks upon that.
Created attachment 436252 [details, diff] when using clang, don't check gcc version This patch skips the gcc check if toolchain says CC is clang.
It appears this patch is missing in 5.1.3.2. The bug occurs when I try to compile with clang. Can anyone re-apply it please?
(In reply to Stephan Menzel from comment #7) > It appears this patch is missing in 5.1.3.2. > The bug occurs when I try to compile with clang. > > Can anyone re-apply it please? The fix was never applied, but until recently (2016-06-26 15:34:47)[1] the compiler checks didn't work unless CPP was set consistently with CC and/or CXX. See bug 582822 for details about the change. 1: https://gitweb.gentoo.org/repo/gentoo.git/commit?id=c65f6083898968b5442eeb66afd4298a3b4264e2
Thanks for the heads up. I just tried to disable the check entirely and still the build failed due to the preprocessor checks mentioned in this bug. What is weird however is how this worked up until now. I've been building libreoffice with clang without any problems for many months now and as far as I can tell the previous ebuilds all contained this check as well so I figure they should have failed all along. This is quite unfortunate because building it with g++ takes so much more time. I suspect it could have something to do with bug #582346 which causes ispc not to build so I am stuck with binary leftovers and llvm/clang is depending on older ispc version. Nice little mess that is.
Fix added to 5.1.4
Well, the patch is applied and the first check now works. The second however still fails: >>> Emerging (48 of 53) app-office/libreoffice-5.1.4.2::gentoo * libreoffice-branding-gentoo-0.8.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * libreoffice-5.1.4.2.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * libreoffice-help-5.1.4.2.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * d62650a6f908e85643e557a236ea989c-vigra1.6.0.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * 1f24ab1d39f4a51faf22244c94a6203f-xmlsec1-1.2.14.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * 17410483b5b5f267aa18b7e00b65e6e0-hsqldb_1_8_0.zip SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * Using: oracle-jdk-bin-1.8 * ERROR: app-office/libreoffice-5.1.4.2::gentoo failed (setup phase): * Sorry, but gcc-4.6 and earlier wont work for some KDE packages. * * Call stack: * ebuild.sh, line 115: Called pkg_setup * libreoffice-5.1.4.2.ebuild, line 287: Called kde4-base_pkg_setup * kde4-base.eclass, line 622: Called die * The specific snippet of code: * [[ $(gcc-major-version) -lt 4 ]] || \ * ( [[ $(gcc-major-version) -eq 4 && $(gcc-minor-version) -le 6 ]] ) \ * && die "Sorry, but gcc-4.6 and earlier wont work for some KDE packages." * This is in eclass/kde4-base.eclass If I comment this check out, the build fails with: checking how to run the C preprocessor... clang++ configure: error: in `/var/tmp/portage/app-office/libreoffice-5.1.4.2/work/libreoffice-5.1.4.2': configure: error: C preprocessor "clang++" fails sanity check See `config.log' for more details
In case it is related: The same bug now also occurs with net-libs/webkit-gtk-2.12.3 It used to build with clang but now it won't. In case of the webkits this is of course even more severe.
