LRN schreef, Op 22-3-2013 17:01:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 22.03.2013 17:17, Keith Marshall wrote:
>> On 22 March 2013 12:37, Gisle Vanem wrote:
>>> Is it? LoadLibraryA() doesn't absolutely need a FreeLibrary().
>>> Windows isn't that lame.
> "... The system unloads a module when its reference count reaches zero or
>>> when the process terminates (regardless of the reference
>> In theory, perhaps; what MSDN claims isn't always borne out in
> MSDN is correct. If you watch the process of dll loading/unloading, in
> normal circumstances W32API will call FreeLibrary() for you, if you
> neglect to do it yourself.
>>> I actually ran guessreturn.exe w/o a libz-1.dll anywhere and got
>>> a '1' as exit-code (errorlevel). The sys-err code was 2 though;
>>> "File not found".
>> Sure. When you don't have libz-1.dll installed, this is what will
>> happen. Did you bother to try *with* libz-1.dll installed? I
>> guess you didn't.
>> I've seen this before. Bad Things (TM) may happen, if you don't
>> clean up behind yourself. Just to confirm that my memory isn't
>> failing, I *installed* MinGW's libz-1.dll, then built and ran LRN's
>> code; here is what I see, (on Windows Vista):
>> This application has requested the Runtime to terminate it in an
>> unusual way. Please contact the application's support team for
>> more information.
>> This was accompanied by a Windows pop-up, inviting me to close the
>> application, which it then did, *without* completing the specified
>> return actions; (the return code was 3).
>> For me, adding:
>> if (h != NULL) FreeLibrary (h);
>> before the return statement, resolved the issue.
> A-a-a-nd 100 karma points are going to-o-o-o... Keith Marshall!
> That said, you only found correct return code (3) after compiling and
> running it yourself, so let's make it 50 karma points :)
> On 22.03.2013 17:26, Eli Zaretskii wrote:
>> I did. Used a slightly different name for the DLL, as my zlib is
>> called differently, but I did try the same program. It returns
>> zero every time I run it.
> Try "libgcc_s_dw2-1.dll" instead of "libz-1.dll"
> (libz is here just to make it more difficult to guess; naming the
> culprit, libgcc_s_dw2, would have taken all the fun away)
> Note that it won't work (that is, the program won't crash) if you're
> using a gcc toolchain with sjlj unwinding (in which case your libgcc
> will be named "libgcc_s_sjlj-1.dll").
> It looks like just having libgcc loaded into memory causes the program
> call __deregister_frame_info() after returning from main(). Even if
> the program itself does not link to libgcc normally (via
> - -shared-libgcc or -lgcc_s_dw2).
> Anyway, the program calls __deregister_frame_info(), then libgcc_s_dw2
> tries to call that function, but crashes inside it. Maybe because
> __register_frame_info() is only called by libgcc, but not by the
> program (sadly, i have no way to track this reliably; it looks like
> the function that actually runs has a different name, and
> __deregister_frame_info/__register_frame_info are just aliases).
> This means that using LoadLibrary() to dynamically load any (!) dll
> that is linked directly (or indirectly) to libgcc will cause this kind
> of crash, unless the program either does explicit FreeLibrary() to get
> rid of libgcc before returning, or is linked to libgcc (directly or
> indirectly) normally by itself (in which case LoadLibrary() does
> nothing, since libgcc is already loaded and mapped into process'
> address space; termination will be performed correctly). Another way
> is to call ExitProcess(), which will, apparently, go around the crt
> [de]initialization code and terminate the process without crashes.
> Now, who would do such a thing? I mean, load a dll, and then not
> unload it? Well, turns out, gstreamer does this (on purpose). Also it
> is advised against unloading anything that depends on libgobject
> (unless your application already links to libgobject) - it was a
> design decision by glib devs to make gobject non-unloadable.
> You might be wondering: why now, all of a sudden?
> Well, i've been compiling my own gettext recently, and discovered 
> that libintl doesn't really depend on libgcc, its apparent libgcc
> dependency is a consequence of the package maintainer's decision to
> just put -shared-libgcc into global LDFLAGS for the whole gettext.
> Because of that dependency, glib and everything that had dependency on
> it (the whole gtk tree and friends) linked to libgcc, indirectly, and
> thus the problem went undetected (i've been building GStreamer for a
> few years now).
In other words, we need to rebuild libintl without -shared-libgcc...