[SERVER-41835] symbol clashes: libgcc vs vendored IntelRDFPMathLib20U1 Created: 20/Jun/19 Updated: 28/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | toolchain-next | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Service Arch
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Ran into a not-quite-diagnosed issue with the LIBDEPS_PRIVATE change in the original attempt at We're doing something wrong. For example, here's a grep for _bid128_to_int32_rnint, among the 'nm' output for each dependency in the 'ldd' output from decimal128_test,
I suspect that the __ (double-underscore) prefix of the libgcc and vendored names is a configurable parameter of the library. If so, our vendored copy of the library should use another prefix. Double underscores are disallowed in identifiers emitted by application-level libraries, so we breaking the C rules by having a vendored library that emits them. This restriction seems a little academic, but here we are with a real problem caused by the violation. |
| Comments |
| Comment by Billy Donahue [ 21/Jun/19 ] | ||||||||
|
After some experimentation, the bid_conf.h is insufficient to rename all the names exported by the library. We should be reluctant to do too much customization inside the library. Need another approach. Some insights into the underlying problem have emerged in the investigation.
By "system's libgcc" above, that really means the toolchain's "-lgcc_s",
And so libgcc.a is statically linked into each
target. When "base" has a LIBDEPS_PRIVATE dep on intelfp, then the static link to libgcc.a's bid* functions happen in each .so and we can't overcome it with later dynamic linking. When "base" instead has a LIBDEPS dep, then the vendored "intel_decimal128" library appears on the link line of each .so, so it is interposed before the "fake" libgcc_s.so linker script (which would otherwise provide libgcc.a's intelfp functions). So because toolchain is using a linker script to force static linking of libgcc_s names, we can't override them using LIBDEPS_PRIVATE. We MUST use public LIBDEPS. | ||||||||
| Comment by Billy Donahue [ 20/Jun/19 ] | ||||||||
|
Yes, the emitted names editable in a bid_conf.h header. https://github.com/mongodb/mongo/blob/master/src/third_party/IntelRDFPMathLib20U1/README#L94-L100
That's a lot of stuff to edit. It would be cute if they left a prefixing system, but maybe we can set one up. |