#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs