#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
--------------------------------------------+------------------------------
Reporter: cypherpunks | Owner: tbb-team
Type: defect | Status:
| needs_revision
Priority: Very High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: ff60-esr, TorBrowserTeam201807 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------------+------------------------------
Comment (by Hello71):
Replying to [comment:23 boklm]:
> Replying to [comment:19 sukhbir]:
> > So the question then is that if it's not `strings`, then what would be
a good way of finding out the installed version of libstdc++ to compare
with the bundled version? Would parsing the `readelf` output be a better
fit?
>
> Maybe we could build a small c++ program linked with our libstdc++ and
using the latest CXXABI. If running this program from `start-tor-browser`
fails then we know that we need to add our libstdc++ to `LD_LIBRARY_PATH`.
isn't that what I said to do?
Replying to [comment:24 boklm]:
> Replying to [comment:14 Hello71]:
> > what's wrong with rpath?
>
> How would it help with this issue? I think using rpath instead of
`LD_LIBRARY_PATH` to use our libstdc++ library does not remove the issue
that our libstdc++ can be too old for `libgdk-3.so.0` or other installed
libraries on some systems.
DT_RUNPATH to be specific, not DT_RPATH. it only applies to the immediate
dependencies, so it solves the immediate problem. it doesn't fix *data*
format changing though, so for example passing a std::string between a new
lib and an old lib might crash or do something bad.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25485#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online