https://jira.mongodb.org/browse/SERVER-24374?focusedCommentId=2287679&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-2287679

Ran into a not-quite-diagnosed issue with the LIBDEPS_PRIVATE change in the original attempt at SERVER-24374. It means that the system's libgcc, which provides its own intelfp names, can seep into dynamic builds of the decimal128_test.

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,
when built with dynamic gcc.

build/dynamic_gcc/mongo/unittest/libunittest_main.so:                      T __bid128_to_int32_rnint
build/dynamic_gcc/mongo/db/libserver_options_core.so:                      T __bid128_to_int32_rnint
build/dynamic_gcc/third_party/IntelRDFPMathLib20U1/libintel_decimal128.so: T __bid128_to_int32_rnint
build/dynamic_gcc/mongo/util/net/libhttp_client.so:                        T __bid128_to_int32_rnint
build/dynamic_gcc/mongo/util/libsecure_compare_memory.so:                  T __bid128_to_int32_rnint

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.