[...] > It is simple, there can only be one definition, if it is > dllexported, it means there is no way to inline it since > it has to be exported. inline is an explicit exception to the one definition rule. [...] > Please do not compare ELF visibility to PE exports, ever. > They are completely unrelated. I accept that they are not identical, but visibility and export very definitely overlap at the conceptual level. >From the gcc doc: "dllexport [...]On systems that support the visibility attribute, this attribute also implies “default” visibility." And this article: http://gcc.gnu.org/wiki/Visibility that definitely compares visibility and dllexport. Perhaps what you meant to say was that the option -fvisibility-inlines-hidden does not apply under Windows. The concept certainly applies, but if the option isn't applicable then I will ignore it. [...] > You can file an enhancement ticket. I'd like to clear this aspect of the discussion, which I was expecting (since there seems to be some strange assumptions about inline and shared library exports going around), in a forum environment rather than on a bug list. The real argument in favour of gcc's current behaviour is that if the executable replaces a symbol address in the import table of a DLL then even the DLL binary should use that replacement. This is a feature that is sometimes used to hook into existing DLLs. However msvc is obviously ignoring this aspect when it comes to inline functions, so it's arguable that gcc should too. Note: When gcc compiles an executable that uses the shared library it will (when it can) inline from the header rather than use the imported function address (sometimes it issues warnings but it still inlines). So any hooking would probably be useless anyway. I have a demo of this inline behaviour based on the OP example if you're interested. I'm not trying to start an msvc vs gcc argument, just trying to demonstrate what is expected of a shared library under Windows. I feel confident saying "expected" because of the many major libraries in which the code is written like the class A (and/or class B) examples of my OP. To ignore this expectation is to say that gcc should not be used to compile such shared libraries under Windows. -- Geoff Worboys Telesis Computing Pty Ltd
