Bug 192928
| Summary: | /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by /usr/local/share/chromium/chrome not found | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jens Grassel <freebsd-ports> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-chromium (Nobody) <chromium> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | beastie, cjpm, des, frank, miwi, newaxekiller, rene, solarcatcher | ||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | amd64 | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Jens Grassel
2014-08-22 19:13:16 UTC
over to maintainer group. (In reply to John Marino from comment #1) > over to maintainer group. (In reply to jan0sch from comment #0) > I've updated to chromium 36.0.1985.143_1 on two machines running 9.3-RELEASE > and get the following error on both of them if I try to start chrome: > > % chrome > /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by > /usr/local/share/chromium/chrome not found > > % strings /usr/lib/libstdc++.so.6 | grep GLIBCXX > GLIBCXX_3.4 > GLIBCXX_3.4.1 > GLIBCXX_3.4.2 > GLIBCXX_3.4.3 > GLIBCXX_3.4.4 > GLIBCXX_3.4.5 > GLIBCXX_3.4.6 > GLIBCXX_3.4.7 > GLIBCXX_3.4.8 > GLIBCXX_3.4.9 > GLIBCXX_FORCE_NEW > > % strings /usr/local/lib/gcc47/libstdc++.so.6 | grep GLIBCXX > GLIBCXX_3.4 > GLIBCXX_3.4.1 > GLIBCXX_3.4.2 > GLIBCXX_3.4.3 > GLIBCXX_3.4.4 > GLIBCXX_3.4.5 > GLIBCXX_3.4.6 > GLIBCXX_3.4.7 > GLIBCXX_3.4.8 > GLIBCXX_3.4.9 > GLIBCXX_3.4.10 > GLIBCXX_3.4.11 > GLIBCXX_3.4.12 > GLIBCXX_3.4.13 > GLIBCXX_3.4.14 > GLIBCXX_3.4.15 > GLIBCXX_3.4.16 > GLIBCXX_3.4.17 > GLIBCXX_DEBUG_MESSAGE_LENGTH > > I have tried to force the ports tree to use gcc-4.7 as described here: > https://www.freebsd.org/doc/en/articles/custom-gcc/configuring-ports-gcc.html > > But the error message didn't go away. Yeah, this also happens during build if the bundled protobuf is used instead of the ports one. But I wonder if this isn't actually a bug in the ports infrastructure or base system. Exact same problem here (please change importance accordingly - it does not only affect jan0sch). I run 9.3-RELEASE and use the official packages supplied by the FreeBSD project. When I start Chromium (chromium-36.0.1985.143_1), I get the same error message as jan0sch. Here you can find a couple of workarounds: https://lists.freebsd.org/pipermail/freebsd-chromium/2014-August/001548.html Thanks, Carlos! Just to clarify the 1st recommendation in that post: The chrome executable under /usr/local/bin/chrome is NOT the ELF binary that needs to be patched with sysutils/patchelf. It is only a shell script which then invokes the real chrome executable at /usr/local/share/chromium/chrome (I found this out because patchelf always through this at me "not an ELF executable: No such file or directory") Thus the full command is: #patchelf --set-rpath /usr/local/lib/gcc47 /usr/local/share/chromium/chrome Now chromium works again! > Thus the full command is:
> #patchelf --set-rpath /usr/local/lib/gcc47 /usr/local/share/chromium/chrome
>
> Now chromium works again!
Many thanks for the hint. Now it runs at least for some time. It seems to chrash now when it tries to sync. :-(
[19245:406609920:0829/141917:ERROR:connection_factory_impl.cc(335)] Failed to connect to MCS endpoint with error -111
(In reply to jan0sch from comment #6) > > Thus the full command is: > > #patchelf --set-rpath /usr/local/lib/gcc47 /usr/local/share/chromium/chrome > > > > Now chromium works again! > > Many thanks for the hint. Now it runs at least for some time. It seems to > chrash now when it tries to sync. :-( > > [19245:406609920:0829/141917:ERROR:connection_factory_impl.cc(335)] Failed > to connect to MCS endpoint with error -111 Please, see bug 192821. A better solution is to set LD_LIBRARY_PATH or LD_PRELOAD in the wrapper script. After investigating a problem similar to this for another port, the problem has come up because chromium now uses "USE_OPENSSL"
in bsd.port.mk, bsd.openssl.mk is included before bsd.gcc.mk
bsd.openssl.mk adds "-Wl,-rpath,/usr/lib:/usr/local/lib" to LDFLAGS unconditionally (when included.)
bsd.gcc.mk tries to determine if the features are in OS base, and if not adds:
"-Wl,-rpath=${_GCC_RUNTIME}" to LDFLAGS.
Because of bsd.openssl.mk, base is searched before ${_GCC_RUNTIME}...
After the latest update to GCC 4.8.3 the recommendations for how to fix this problem do not seem to work (at least for the "official" package chromium-37.0.2062.120_2). Neither a wrapper with LD_LIBRARY_PATH=/usr/local/lib/gcc48 /usr/local/share/chromium/chrome $* Nor patchelf way seem to do any good. Actually both make chromium fail silently. Does anybody have an idea how to get chromium to run again? Still actual for chromium-37.0.2062.124 on FreeBSD 9.3-PRERELEASE. When I use LD_LIBRARY_PATH=/usr/local/lib/gcc48 wrapper, I get: Bus error (core dumped) Created attachment 147789 [details]
Truss output from the silent failure of chromium with LD_LIBRARY_PATH
I'm seeing the problem with gcc 4.8 and chromium 37 as well; I'm also seeing the silent failure when I add LD_LIBRARY_PATH. I've added (slightly trimmed) truss output from that silent failure. If someone familiar with the code could take a look, I think we would all appreciate it. So far I haven't been able to find a workaround. Annoying in the extreme, as I use chromium as my primary browser. BTW, in my case it's 9.1-stable. Is this still a problem with Chromium 47? Chromium 47 seems to work fine on 9.3 and 10.2. Problem solved, close. Thanks all :) |
