[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Static library support for GTK+

From: Martin Gerhardy
Subject: Re: [Mingw-cross-env-list] Static library support for GTK+
Date: Fri, 25 Nov 2011 08:25:44 +0100

Am Donnerstag, den 24.11.2011, 16:31 +0100 schrieb Matthias Gehre:
> As mentioned in another thread,
> I'm currently building lightspark with option (C)  (one big DLL),
> but I needed to apply some fixes, which should make option (A) work, too.
> The problem is, that glib,gtk's and so on DllMain gets not called,
> which is needed to setup a few things. Usually it sets a HINSTANCE
> variable, so that
> one can find the installation directory with that.
> Glib's DllMain does even more things like
> setting up some thread related stuff (I haven't looked up all of those
> functions called from DlllMain).
> Without that, glib_spawn will fail, for example, because it cannot
> find the gspawn-helper.exe application.
> I cannot see another difference between static and dynamic library
> than not calling DllMain.
> My approch was to export all those DllMain's as, say, glib_DllMain,
> and then call them from within my 'big' Dll's
> DllMain.
> For option (A), the setting of a hinstance variable can of course
> fixed somehow. (Actually, using hinstance=NULL gives
> the path of the current executable, which would be just right. Then
> one only has to make sure that the executable exports
> all symbols required by dlopen' like procedures)
> But DllMain is also called on thread attach/detach, which can be hard
> to emulate by other means.
> Best wishes,
> Matthias

Hi Matthias,

i'm having the same problems with gtk and gtkglext libs here. They don't
initialize correctly. I'm highly interested in a working solution, as
static linking is currently just not working with our gtk project


reply via email to

[Prev in Thread] Current Thread [Next in Thread]