Created attachment 24142 [details] Test library and app as illustration of the bug. Attached is a test application and a shared library it is linked with. If the wrong copy constructor is used, it will write an error. Both the application and the library have a local but different class "TestObject". Both application and library use a std::pair<TestObject, void*>. When the copy constructor of the library's TestObject is called by the std::pair in the library, the copy constructor from the application's TestObject is used. This does not happen if the application doesn't have a std::pair<TestObject, void*>. Tested ok with 4.1.3. Failed with 4.2.1, 4.3.4, 4.4.1, 4.5.1 (I couldn't test it readily with a more recent version.)
Confirmed. Even with -fvisibility=hidden we have 28: 0000000000000000 17 FUNC WEAK HIDDEN 13 _ZN10TestObjectC2Ev 29: 0000000000000000 17 FUNC WEAK HIDDEN 13 _ZN10TestObjectC1Ev 33: 0000000000000000 46 FUNC WEAK DEFAULT 15 _ZNSt4pairI10TestObje ctPv 37: 0000000000000000 46 FUNC WEAK DEFAULT 15 _ZNSt4pairI10TestObje ctPv You can work around this by linking the shared library with -Bsymbolic to force local symbol resolution.
Created attachment 24181 [details] Example with custom allocator Thank you for the workaround. Little side note: this bug also applies to stl containers using a custom allocator that happens to have the same name and occurs in both the application and the library. Allocation is done using the library's allocator, but deallocation is done using the application's. (The workaround also works in this case.)
Are you saying that you have classes that have the same name but are different? This violates the One Definition Rule, no?
I don't think it does, but it also doesn't matter for this bug report; symbols are not hidden while they should be.
*** Bug 50270 has been marked as a duplicate of this bug. ***
I would be curious to know if you are seeing something else when you configure your build with --disable-visibility.
no side effects for the time being. I've tried only small applications though. I would suggest to rename --disable-visibility --disable-std-visibility or similar as, applied to top level configure, it is not very informative about its semantics
Vincenzo, I agree about the name, yesterday had the same thought. Then we have the usual annoyances with configure options and switches, we normally don't want to just rename in order to not break build systems, scripts, etc. I'll see what we can do, ideally add an alias and deprecate the old one.