On Fri, 2018-07-20 at 10:17 +0100, Jonathan Wakely wrote: > > is seen as invoking valgrind's operator new implementation rather > > than malloc. > > Looks like a valgrind bug. I have discovered the problem: it wasn't a GCC issue or a Valgrind issue. The problem is that I am linking ICU as a shared library now (previously I was linking it as a static library), plus using the -static-libstdc++ option to embed libstdc++ into my software so it will run on systems with much older instances of GCC available. I was adding this option to both the ICU shared libraries and to my program that links them. The ICU shared library was including libstdc++'s global operator delete (e.g., nm shows it exists in the ICU .so with type "T"). Since both the shared library and my program are compiled/linked with the identical version of GCC, in fact the code is the same but Valgrind apparently does not like this situation at all. If I re-link the ICU shared libraries without -static-libstdc++ then it is satisfied. Now my question is: I see that when I run ldd on my program it lists /lib64/libstdc++ as a prerequisite. Will the -static-libstdc++ option in my program be sufficient to satisfy the code in the ICU shared library? Or will it now actually try to load the system libstdc++, for ICU, in addition to the one statically linked into my program? I'm not sure how the linkage will be resolved here. Or, is there a way to find out (some utility which will show me how the runtime linker will set it up)? Maybe someone on the binutils list might know? Cheers!
