Apparently, at least some parts of chromium are built with clang now and chromium build system is not aware of the default c++ library selection. That is, the selection between libcxx and libstdc++ which might be changed by "default-libcxx" use-flag on sys-devel/clang. From the build log: <...> x86_64-pc-linux-gnu-clang++ -MMD -MF obj/gpu/config/config_sources/gpu_control_list.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCR_CLANG_REVISION=\"321529-2\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGPU_IMPLEMENTATION -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_32 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -I../../third_party/mesa/src/include -I../.. -Igen -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Igen/shim_headers/re2_shim -Igen/shim_headers/libpng_shim -Igen/shim_headers/libjpeg_shim -Igen/shim_headers/zlib_shim -Igen/shim_headers/libdrm_shim -I../../third_party/khronos -I../../gpu -I../../third_party/mesa/src/include -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/encode -I../../third_party/skia/include/gpu -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/vulkan/include -I../../third_party/skia/src/gpu -I../../third_party/skia/src/sksl -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../third_party/angle/include -I../../third_party/angle/src -I../../third_party/angle/src/common/third_party/base -Igen/angle -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -fcolor-diagnostics -no-canonical-prefixes -m64 -march=x86-64 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Wno-unused-lambda-capture -Wno-user-defined-warnings -Wno-enum-compare-switch -Wno-tautological-unsigned-zero-compare -Wno-null-pointer-arithmetic -Wno-tautological -constant-compare -Wtautological-constant-out-of-range-compare -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautologica l-overlap-compare -std=gnu++14 -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -O2 -pipe -march=native -m64 -c ../../gpu/config/gpu_control_list.cc -o obj/gpu/config/config_sources/gpu_control_list.o <...> python "../../build/toolchain/gcc_link_wrapper.py" --output="./viz.service" -- x86_64-pc-linux-gnu-clang++ -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -m64 -Wl,-O1 -Wl,--gc-sections -Wl,-rpath-link=. -Wl,--disable-new-dtags -Wl,--export-dynamic -Wl,-O1 -Wl,--as-needed -o "./viz.service" -Wl,--start-group @"./viz.service.rsp" -Wl,--end-group -ldl -lpthread -lrt -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -latomic -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpng16 -lz -lfreetype -lexpat -lfontconfig -lwebp -lwebpdemux -lwebpmux -ljpeg -lX11 -lX11-xcb -lxcb -lXcomposite -lXcursor -lXdamage -lXext -lXfixes -lXi -lXrender -lXtst -ldrm -lre2 -lharfbuzz -lXrandr -lpci -lXss -lgio-2.0 -lresolv -lasound -lavcodec -lavformat -lavutil -lsnappy -lopus obj/gpu/config/config_sources/gpu_control_list.o: In function `gpu::(anonymous namespace)::StringMismatch(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char const*)': ../../gpu/config/gpu_control_list.cc:(.text._ZN3gpu12_GLOBAL__N_114StringMismatchERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEEPKc+0xe5): undefined reference to `re2::RE2::RE2(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)' clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) As can be seen from the last line, some objects are using std::__1 namespace for c++11-related stuff (ie from libcxx, not std::__cxx11 from libstdc++); in my case, sys-devel/clang is built with default-libcxx enabled and that is causing the problem. The build system should probably enforce `-stdlib=libstdc++` when using clang, since the rest of the system is built with gcc and uses libstdc++ -- including dev-libs/re2 (the reported symbol is from this library). Or maybe there is some other way to make this work, since usage of libcxx might be actually intended (just simply ewarn?). Versions and flags: sys-devel/clang-5.0.1:5 default-compiler-rt default-libcxx static-analyzer xml -debug -doc -test -z3 ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="-FreeBSD" LLVM_TARGETS="X86 -AArch64 -AMDGPU -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore" PYTHON_TARGETS="python2_7" sys-devel/llvm-5.0.1:5 gold ncurses -debug -doc -libedit -libffi -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="-Darwin" LLVM_TARGETS="X86 -AArch64 -AMDGPU -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore" sys-libs/libcxx-6.0.0:0 libcxxrt libunwind static-libs -libcxxabi -test ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" ELIBC="glibc -musl" sys-devel/gcc-7.3.0:7.3.0 cxx fortran go mpx nptl openmp pie sanitize ssp vtv -altivec -awt -cilk -debug -doc -fixed-point -gcj -graphite -hardened -jit -libssp -multilib -nls -objc -objc++ -objc-gc -pch -pgo -regression-test -vanilla www-client/chromium-65.0.3325.146:0 cups custom-cflags pic proprietary-codecs system-ffmpeg -component-build -gnome-keyring -hangouts -jumbo-build -kerberos -neon -pulseaudio -selinux -suid -system-icu -system-libvpx -tcmalloc -widevine
Created attachment 524320 [details] build.log.gz
Now that bug 650082 has been fixed, this also happens with clang:6
If I understand this correctly, this means that dev-libs/re2 needs an option to be built with sys-devel/clang / against sys-libs/libcxx, or the bundled copy has to be used.
> dev-libs/re2 needs an option to be built with sys-devel/clang / against sys-libs/libcxx, or the bundled copy has to be used. Going this way, it would also mean each c++ library which is a system dependency (ie not a bundled one) of chromium should have an option to be built against libcxx or become bundled. The first can be done (without a dedicated use-flag) via package.env. But then it would break other dev-lib/re2 users, which are built against libstdc++. I'm not sure that using clang with libcxx system-wide is officially supported on gentoo (whilst one is free to do so on one's own), so providing a use-flag for chromium (regarding libcxx/libstdc++) and enforcing the choice via `-stdlib=` flag seems reasonable. It would prevent the breakage, but still provide means to use libcxx system-wide. Is there any problems with this?
(In reply to Alexander Sergeyev from comment #4) > > dev-libs/re2 needs an option to be built with sys-devel/clang / against sys-libs/libcxx, or the bundled copy has to be used. > > Going this way, it would also mean each c++ library which is a system > dependency (ie not a bundled one) of chromium should have an option to be > built against libcxx or become bundled. The first can be done (without a > dedicated use-flag) via package.env. But then it would break other > dev-lib/re2 users, which are built against libstdc++. > > I'm not sure that using clang with libcxx system-wide is officially > supported on gentoo (whilst one is free to do so on one's own), so providing > a use-flag for chromium (regarding libcxx/libstdc++) and enforcing the > choice via `-stdlib=` flag seems reasonable. It would prevent the breakage, > but still provide means to use libcxx system-wide. Is there any problems > with this? I was looking into making www-client/chromium use a specific C++ library (libcxx or libstdc++), but could not quickly determine which mechanism it chooses / offers for the selection. There is `use_custom_libcxx`, but that seems to always use a bundled library, instead of allowing the user to specify which to use.
> could not quickly determine which mechanism it chooses / offers for the selection chromium build system uses both gcc and clang and has some workarounds to prevent linking with particular c++ std libraries by default (build/config/posix/BUILD.gn); so, I guess, having no obvious handle for the stdlib selection, it's unlikely to be easy [to do reliably]. It might be possible to hack this around with a clang/clang++ (shell) wrapper which would "fix" cmdline and then exec real clang/clang++. Though, looking at build/toolchain/gcc_toolchain.gni, this might complicated as well. There always an option to direct the issue upstream.
I don't see any sane way to deal with this in the chromium ebuild. You can add whatever options are necessary on your system to CXXFLAGS/LDFLAGS via package.env.
(In reply to Mike Gilbert from comment #7) > I don't see any sane way to deal with this in the chromium ebuild. With sys-devel/clang[+default-libcxx] chromium will fail to build. That is a broken ebuild. A way to fix this is to change chroimum DEPEND to include sys-devel/clang[-default-libcxx]. > You can add whatever options are necessary on your system to CXXFLAGS/LDFLAGS via package.env. This won't work as is. The same flags apply to gcc and clang. And gcc don't have -stdlib switch: g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?
(In reply to Alexander Sergeyev from comment #8) > (In reply to Mike Gilbert from comment #7) > > I don't see any sane way to deal with this in the chromium ebuild. > > With sys-devel/clang[+default-libcxx] chromium will fail to build. That is a > broken ebuild. A way to fix this is to change chroimum DEPEND to include > sys-devel/clang[-default-libcxx]. That only supports your particular use case. There may be other users who have build various libraries on their system against libcxx. > > You can add whatever options are necessary on your system to CXXFLAGS/LDFLAGS via package.env. > > This won't work as is. The same flags apply to gcc and clang. And gcc don't > have -stdlib switch: The chromium ebuild never calls gcc or g++, so that should be fine. Just use package.env.
(In reply to Mike Gilbert from comment #9) > The chromium ebuild never calls gcc or g++, so that should be fine. Just use > package.env. Hm. For some reason I believed that it uses clang only for certain components. Thank you! PS. I guess, the bottom line here is to avoid sys-devel/clang[+default-libcxx] unless libcxx is used system-wide.
Note that if I can get chromium to consistently build with gcc again, I will stop forcing clang in the ebuild. Just something to be aware of in the future.
*** Bug 658290 has been marked as a duplicate of this bug. ***
