Chromium can be built with clang, but the gyp build system needs to be told about that; otherwise, the build fails. See http://code.google.com/p/chromium/wiki/Clang Reproducible: Always Steps to Reproduce: 1. Install clang-3.1 2. Try to build chromium with CC=clang CXX=clang++ Actual Results: Build fails.
Created attachment 315915 [details, diff] ebuild patch This ebuild patch adds the required input to the build system. With clang-3.1 and chromium-19.0.1084.56-r1, it builds and runs perfectly.
1. Thank you for reporting this and writing the patch. Some remarks: - you shouldn't need GYP_DEFINES - you can use grep -q instead of redirecting to /dev/null 2. What are the exact errors? I'd prefer to fix things upstream so that it works out-of-the-box rather than having to special-case clang in the ebuild. Please attach full build log. 3. Please work against the most recent version of Chromium, i.e. dev channel (hard masked) or 9999.
I don't have the exact errors; IIRC it's something in the skia library using the 'restrict' keyword. But that's how it was meant to be. The build system will assume that you're using gcc unless you tell it you're using clang, in which case it will do various things, like add preprocessor definitions, to compile properly. I suggest you don't bother the developers about this; they'll probably just point you to the wiki page I linked. AFAIK, their build system doesn't do much detection of the environment in the first place, and I assume they'll be reluctant to add some compiler detection. As far as my patch is concerned, I don't know exactly what is needed - GYP_DEFINES, the "-Dclang=1" argument, or both. Judging by the wiki page, probably just GYP_DEFINES (I'm not sure how the two differ). I trust you'll be able to make any changes to my patch you deem necessary.
Upstream bug about not compiling with clang out of the box: http://code.google.com/p/chromium/issues/detail?id=94304
(In reply to comment #3) > I don't have the exact errors; IIRC it's something in the skia library using > the 'restrict' keyword. But that's how it was meant to be. The build system > will assume that you're using gcc unless you tell it you're using clang, in > which case it will do various things, like add preprocessor definitions, to > compile properly. I was able to build trunk successfully on Gentoo using clang (from the source tree, not ebuild). So far no errors.
Created attachment 327010 [details] chromium-22.0.1229.94 build log (failed) /var/tmp/portage/www-client/chromium-22.0.1229.94/work/chromium-22.0.1229.94/out/Release/obj/gen/nacl_bootstrap/../../../obj.target/nacl_bootstrap_lib/ native_client/src/trusted/service_runtime/linux/nacl_bootstrap.o: In function `handle_bss': native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:(.text.handle_bss+0xce): undefined reference to `memset'
Created attachment 327012 [details] chromium-23.0.1271.26 build log (failed) /var/tmp/portage/www-client/chromium-22.0.1229.94/work/chromium-22.0.1229.94/out/Release/obj/gen/nacl_bootstrap/../../../obj.target/nacl_bootstrap_lib/ native_client/src/trusted/service_runtime/linux/nacl_bootstrap.o: In function `handle_bss': native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:(.text.handle_bss+0xce): undefined reference to `memset'
This NaCl failure is known since at least June 2012, and chromium-19.0.1084.52. Note this interesting snippet in src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.gyp: 'conditions': [ ['clang==1', { 'cflags': [ # Prevent llvm-opt from replacing my_bzero with a call # to memset '-ffreestanding', # But make its <limits.h> still work! '-U__STDC_HOSTED__', '-D__STDC_HOSTED__=1', # TODO(bbudge) Remove this when Clang supports -fno-pic. '-Qunused-arguments', ], }], ],
Then again, what's the problem with defining clang=1 in the ebuild, which is obviously how it's supposed to be done?
(In reply to comment #9) > Then again, what's the problem with defining clang=1 in the ebuild, which is > obviously how it's supposed to be done? Ebuilds should not detect compiler version and act differently based on it. It's fragile, and makes the build more complicated. One part of portability is that you shouldn't manually "configure" the compiler, the size of various data types, etc. Upstream fix submitted for review: https://codereview.chromium.org/11234020/ By the way, if one person from upstream says something about what he thinks is the right way, that doesn't necessarily mean it's the right way for Linux packaging.
This is fixed for chromium-24.x and newer. chromium-23.x is known not to work. Please file new bugs if there are any regressions.
