[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13359 [Tor Browser]: Linux: update fails because bundled libstdc++.so.6 is not found

#13359: Linux: update fails because bundled libstdc++.so.6 is not found
-----------------------------+----------------------
     Reporter:  mcs          |      Owner:  gk
         Type:  defect       |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  ff31-esr
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by gk):

 Replying to [comment:10 mcs]:
 > > I'd test the one mentioned in comment:4 but I currently lack the
 update testing setup. mcs: can you think of trying this idea (does not
 matter if you still have your tor related system libs installed in this
 case)? Would a patch from my side be of help (it would basically copy the
 libstdc++ into the tor lib directory instead of the browser directory)?
 >
 > Kathy and I tried this for a 4.0-alpha-3 to nightly upgrade.  Our quick
 and dirty approach was to move libstdc++.so from Browser/ to
 Browser/TorBrowser/Tor/ after the update was applied (but before clicking
 "Restart to Update").  The browser (and tor) restarted without error.  In
 fact, if you set devtools.chrome.enabled = true, open the browser console,
 and then type the following you can see LD_LIBRARY_PATH:
 >
 >
 alert(Cc["@mozilla.org/process/environment;1"].getService(Ci.nsIEnvironment).get("LD_LIBRARY_PATH"));
 >
 > After successfully restarting, the above shows that LD_LIBRARY_PATH is
 still set to /home/brade/Desktop/tor-browser/Browser/TorBrowser/Tor/ (the
 same value it had in 4.0-alpha-3 before we applied the update).  So the
 update process is not touching LD_LIBRARY_PATH; the real problem is that
 the LD_LIBRARY_PATH value used in 4.0-alpha-3 is not sufficient for the
 ESR31-based browser.

 Ah, yes, that makes sense. Thanks for trying.

 > It would still be nice to embed a relative rpath but it seems that
 moving libstdc++.so is an acceptable workaround if that proves to be too
 messy.

 Given the issues I mentioned in my previous comment and our lack of time I
 am in favor of moving libstdc++. Seems less risky than hotfixing this with
 -rpath although that is preferable in the longer run.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13359#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs