[SERVER-55522] Prefix all shared libraries produced by the server build with libmongo rather than plain lib Created: 25/Mar/21 Updated: 27/Oct/23 Resolved: 27/Oct/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive) |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Development Platform
|
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Dev Platform 2021-04-19, Dev Platform 2021-05-03 |
| Participants: |
| Description |
|
In dynamic builds we produce a library called libunwind.so. Things that link to it end up with DT_NEEDED entries that reference libunwind.so. That's not a great idea: the system almost surely has a libunwind.so and it surely isn't the one we intend things to use at load time. Normally, it shouldn't be a problem because our DT_RUNPATH uses $ORIGIN or the macOS analogue, so we will look in our PREFIX_LIBDIR first. But other things can get in the way, like an errant LD_LIBRARY_PATH, since LD_LIBRARY_PATH is searched before DT_RUNPATH. This exact situation has happened to developers and led to great confusion. We can leverage the SCons SHLIBPREFIX variable to have all of our libraries come out with a libmongo_ prefix. So we would have libmongo_unwind.so, libmongo_tcmalloc_minimal.so. Due to the way libdeps works, we wouldn't need to actually replace any of the library references in our existing LIBDEPS declarations in our SConscripts, so the change required to make this safety improvement is quite small. |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 25/Mar/21 ] |
|
We could also just do this for the libs under third_party if we wanted to be less aggressive, but I don't see reason not to do it globally. |