Am 27.08.2012 15:45, schrieb Jérôme Gardou:
Hi.
Please see the inlined answers.
Timo Kreuzer a écrit :
Hi,
I don't agree with these changes.
If we need a DllEntry in the lib, then we should use the one that is provided by mingw-w64 (all this code is 100% mingw-w64). It simply returns true (thats exactly what the one in MS CRT does) and works for gcc and MSVC.
There is DllEntryPoint in the code base, but no DllMain. Is it what you are talking about?
No, I was talking about DllMain. It is not in our codebase, but in mingw-w64. I even have the file in my working copy, probably from the last sync, but I didn't commit it for whatever reason.
Also what's the point of DisableThreadLibraryCalls() here? As you wrote yourself, no DllMain only means "I have nothing more to initialize than the CRT". But this disables the CRT thread initializion, too.
You have a point. If nothing is given, then the programmer could assume that nothing happens. Regarding CRT thread initialization: DisableThreadLibraryCalls means that the DLLs ahs nothing to initialize on thread creation, and that the loader can gain some performance in skipping this DLL. We have some Dlls that call it, and if this is a problem with our CRT, then this is bad. Quoting MSDN: "Do not call this function from a DLL that is linked to the static C run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and DLL_THREAD_DETATCH notifications to function properly" Reading between the lines, that means that every CRT thread initialization is done in msvcrt.dll, and nowhere else. What we link statically to our DLLs shouldn't have anything to do on thread initializations.
In fact, MS uses 2 versions of DllMain. One in the static crt and one in msvcrt.lib. And the latter does in fact call DisableThreadLibraryCalls. So you are right. The DllMainCRTStartup from mingw-w64 handles them, but the code is so ***** that I didn't see, that this runs into nowhere and it does not do anything with them. We just need to make sure this DllMain is not included in our static CRT, even though that one is probably not usable for compiling a proper dll anyway.
There is also no need for weak symbols, we can simply call the stub DllMain, since it doesn't (shouldn't) do anything.
As said in the comment, link.exe choses symbols defined in the object files it is given, and then in the libraries. So adding a stubbed version of dllmain in our library is harmless (unless someone puts his DllMain in a static library and links to that library.) I don't really know about ld behaviour regarding this case, and the "--allow-multiple-definition" option of ld (see http://sourceware.org/binutils/docs-2.22/ld/Options.html#Options ) scares me.
That is normal and expectable linker behaviour. LD works the same way (unless it's totally fubar). The function from the lib does not get included, if it's present in the main object files. (This only works on a per file basis. So when the function was in the same compilation unit as a second function that was linked into the dll, then the function would also be forced in and it would result in an error about multiple definitons.) So under the circumstance that the programmer is sane and doesn't put his DllMain into a static library, you can happily add a stubbed version.
Therefore I suggest: - Add the DllMain for both GCC and MSVC - Don't use a weak symbol and do not check "if (DllMain)" and instead keep the original code unmodified
Please don't make unneccessary modifications to 3rd party code, based on the fear, that LD *might* be broken.
Thanks, Timo