GNOME Bugzilla – Bug 660731
Don't use DllMain if compiling for static library
Last modified: 2015-06-08 10:45:25 UTC
Created attachment 198049 [details] [review] Dont define DllMain if doing static compilation Both GTK and GDK declare DllMain() which breaks static compilation. I realize very few people would ever want to compile these things statically but I did, and maybe others want to as well, and this allows for that (if GDK_STATIC_COMPILATION and GTK_STATIC_COMPILATION are defined, respectively). Patch attached.
-static HMODULE gtk_dll; +static HMODULE gtk_dll = 0; why?
Habit since I was there in the code. Feel free not to do it.
In GLib I just added a non-conditional DllMain. We really need it for the thread detach case to cleanup after GPrivate. I think the plan was to move away from supporting static builds...
On Windows static builds never were meant to be supported. If one actually looks into usage of the gtk_dll variable in gtkmain.c one regression will be dynamically locating the locale files.
@Hans: how? Usually the DLL and the EXE are installed side by side. If gtk_dll is NULL (for static programs) and path based of using that as a handle will automatically default to the path of the EXE. I haven't looked at the code right now to see if it is used some other way. Considering that the advise is to never have GTK be a shared component, I think it is a huge mistake to *require* DLL's. If you cant use it as a shared component and you only have one EXE, it makes no sense to force a user to clutter their distribution with a bunch of DLL's for no good reason. Locating locale files isn't a good reason. As for the GPrivate cleanup stuff ... well, if that's something that only needs to happen at program exit time, why not install an atexit handler? Again, I haven't looked at the code you wrote Ryan that *requires* a DLL. I genuinely hope there is another way to solve the problem becuase more on Windows than other platforms, static makes more sense.
not program exit: thread detach (ie: when a thread exits).
You need to be quite careful about what you do in DllMain. Here's an example: http://blogs.msdn.com/b/oldnewthing/archive/2004/01/28/63880.aspx Also since all your code does is call g_thread_win32_thread_detach(), and all you care about is that the thread is exiting, why not have an API function for thread exit and simply make that call as the last thing in that API? Like at the end of g_thread_exit(). Or ensure that when a thread is created, that the thread function is a wrapper function that calls the thread function passed to g_thread_new() and then does cleanup? I really strongly think you need to consider your approach. Static builds worked just fine up until your change and static builds are very useful. So in essence, that change you made is a regression. It is also sensitive to DisableThreadLibraryCalls() which will break your code if called. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686724%28v=vs.85%29.aspx suggests (at the end) and alternate approach to thread termination. Have you considered that approach. I am not an expert by any means on Windows threads but it seems like the regression you introduced can be avoided.
The old code called the thread detach code from g_thread_exit() but that caused leaks when using GLib code (like anything that used the slice allocator) from threads that were not created by GLib. That's why it was changed to require DllMain().
Created attachment 202244 [details] Log of a cross-compilation attempt Here's a log of a failed cross-compilation; I think I'm on the right bug here.
Avuton, Not sure what that comment was about really, or what it has to do with removing DllMain for static compiles? I don't think you're on the right bug at all.
*** Bug 678387 has been marked as a duplicate of this bug. ***
The crux of this bug comes down to a pretty simple fact: TLS on Windows does not have destroy notifies so we need to know when threads exit so that we can clean up. We do this using the DLL_THREAD_DETACH case of DllMain which we can only have when glib is compiled as a DLL. TL;DR: we cannot support the existing API of GPrivate with static builds of glib on Windows. Unless anyone who knows Windows has another solution to this problem then I think we need to declare static builds of glib on Windows to be unsupported.
(In reply to Ryan Lortie (desrt) from comment #12) > Unless anyone who knows Windows has another solution to this problem then I > think we need to declare static builds of glib on Windows to be unsupported. If someone does come up with a solution, feel free to reopen this bug.