[Bug]: Sanitizer options may disagree between library and user leading to ODR violations

[nextsilicon-itay-bookstein]

Describe the issue

I got an ODR violation stemming from compiling the library without sanitizers and linking against it from code that is compiled with sanitizers enabled. The definition and behavior of some data structures (such as raw_hash_set) changes according to ABSL_HAVE_ADDRESS_SANITIZER or ABSL_HAVE_MEMORY_SANITIZER, and these detect the sanitizer state in the translation unit into which they're included, so ODR violations ensue.

I think perhaps the sanitizer state of the library needs to be "frozen" at build time and propagated as build flags to consumers a-la pkg-config, rather than relying on it matching between library and user.

Steps to reproduce the problem

Compile the abseil library with sanitizers disabled, link against it from a translation unit in which sanitizers are enabled, try to insert into e.g. an absl::flat_hash_map.

What version of Abseil are you using?

I tried to upgrade our abseil dependency from 20220623.0 to 20230125.3 and ran into the above issue.

What operating system and version are you using?

Linux/debian-10

What compiler and version are you using?

clang-16

What build system are you using?

cmake 3.27.9, and I depend on Abseil through Conan.

Additional context

No response

[ediap]

We also encountered a similar issue. We have not observed this issue with older version 20211102.0, which we changed to 20240116.2. Bumping version to the latest tagged release does not help.
Basically, in our case, we need to use legal-approved pre-compiled versions of external libraries (company policy). Abseil is one of them. When using an ASAN build (GCC 13) of our tools linked to a non-asan build of Abseil we encounter the following crashes from absl::flat_hash_map (name of libraries obfuscated):
SIGSEGV caught. zzzz.so.8(+0x7b2e1)[0x2b61488972e1] xxxx.so(_Z13signalHandleri+0x329)[0x2b614bbd4da6] /lib64/libpthread.so.0(+0xf630)[0x2b6176766630] yyyy.exe(ZN4absl12lts_2024011618container_internal19HashSetResizeHelper15InitializeSlotsISaIcELm40ELb0ELm8EEEbRNS1_12CommonFieldsEPvT+0x140)[0x9b78cc] yyyy.so(ZN4absl12lts_2024011618container_internal12raw_hash_setINS1_17FlatHashMapPolicyINSt7_cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKS9_SB_EEE6resizeEm+0x1cb)[0x2b6162e20a2d] yyyy.so(ZN4absl12lts_2024011618container_internal12raw_hash_setINS1_17FlatHashMapPolicyINSt7_cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKS9_SB_EEE14prepare_insertEm+0x110)[0x2b6162e20ff4] yyyy.so(ZN4absl12lts_2024011618container_internal12raw_hash_setINS1_17FlatHashMapPolicyINSt7cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKS9_SB_EEE22find_or_prepare_insertIPKcEESF_ImbERKT+0x8d2)[0x2b6162e24454] yyyy.so(ZNK4absl12lts_2024011618container_internal12raw_hash_setINS1_17FlatHashMapPolicyINSt7cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKS9_SB_EEE19EmplaceDecomposableclIPKcJRKSt21piecewise_construct_tSt5tupleIJOSN_EESR_IJOSB_EEEEESF_INSJ_8iteratorEbERKT_DpOT0+0xe0)[0x2b6162e26170] yyyy.so(ZN4absl12lts_2024011618container_internal15memory_internal17DecomposePairImplINS1_12raw_hash_setINS1_17FlatHashMapPolicyINSt7_cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKSB_SD_EEE19EmplaceDecomposableEOPKcSt5tupleIJOSD_EEEEDTclcl7declvalIT_EEcl7declvalIRKT0_EEL_ZSt19piecewise_constructEcl7declvalISQ_IJSU_EEEEcl7declvalIT1_EEEEOST_SH_ISX_SY_E+0x32)[0x2b6162e263ed] yyyy.so(ZN4absl12lts_2024011618container_internal13DecomposePairINS1_12raw_hash_setINS1_17FlatHashMapPolicyINSt7cxx1112basic_stringIcSt11char_traitsIcESaIcEEEP16lib_model_structEENS1_10StringHashENS1_8StringEqESaISt4pairIKSA_SC_EEE19EmplaceDecomposableEJSG_IPKcSC_EEEEDTcl17DecomposePairImplcl7forwardIT_Efp_Ecl8PairArgsspcl7forwardIT0_Efp0_EEEEOSP_DpOSQ+0xa5)[0x2b6162e264a3] ...
Is there any recommended solution/workaround for the above issue, so we can still test our code using absl::flat_hash_map with AddressSanitizer?