Summary: | =www-client/chromium-65.0.3325.146: undefined reference to `re2::RE2::RE2(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Sergeyev <sergeev917> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | dschridde+gentoobugs, EoD, me, quentin, xdev52 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log.gz |
Description
Alexander Sergeyev
2018-03-18 20:54:49 UTC
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. *** |