Re: PATCH: Fix DLL constructors on OpenBSD
Alexandre Julliard <julliard(a)winehq.org> writes:
The way it normally works is that the _init() function is built from the contents of the .init section, so if you add code in .init it's supposed to show up in _init().
Ah, right. This doesn't work on OBSD because __init() is fully defined in crtbeginS.c, instead of being split between crtbegin and crtend as in most gcc targets, so code added to .init is not executed.
[....] So there are two separate mechanisms, and the constructors are built on top of the .init stuff. In our case we need to be in .init because the constructors are normally called after the rest of the .init code.
It doesn't appear that the .init code on OpenBSD does anything before calling the functions listed in .ctors. (Well, that's not quite true: it sets a flag before calling the ctors.) As long as the foo.spec.o file is listed early on the linker's command line, its constructor(s) should be called before any others. The .so's destructors are called in the reverse order. What is it that _init() does on Linux, that the DLL init code needs to run first? I'd be interested in trying to write an autoconf test or something, if possible. Wim.
wiml(a)underhill.hhhh.org (Wim Lewis) writes:
What is it that _init() does on Linux, that the DLL init code needs to run first? I'd be interested in trying to write an autoconf test or something, if possible.
I believe there was a problem with constructors being called in reverse link order. Also any object file of the dll can potentially have a .init section which would then break badly. Anyway, that constructor stuff is going to change, because we need to intercept constructors and run them from the dll entry point. I'm working on a patch to do that, which will hopefully solve your problem at the same time. -- Alexandre Julliard julliard(a)winehq.com
In <87r7yg4n69.fsf(a)mail.wine.dyndns.org>, julliard(a)winehq.org wrote:
I believe there was a problem with constructors being called in reverse link order. Also any object file of the dll can potentially have a .init section which would then break badly.
I guess configure could test the constructor semantics, since I think neither of these would be issues on OpenBSD ...
Anyway, that constructor stuff is going to change [...]. I'm working on a patch to do that, which will hopefully solve your problem at the same time.
... but this seems like a better idea. I'll wait for your patch and see how it goes. :-)
Dear Alexandre Please explain in a few words what you're going to do. Is this going to effect C++ Global data constructors as well. I'm Just working, well more like fumbling, on a problem in STLPort with global initialization of cout cin cerror (stdout stdin stderror). Is it possible that, while in a global C++ constructor, I am meeting an uninitialized DLL Jump table (I'm not sure what is the official name for it). Is the jump table initialized after the glib c "global_ctors_aux" chain? Alexandre Julliard wrote:
wiml(a)underhill.hhhh.org (Wim Lewis) writes:
What is it that _init() does on Linux, that the DLL init code needs to run first? I'd be interested in trying to write an autoconf test or something, if possible.
I believe there was a problem with constructors being called in reverse link order. Also any object file of the dll can potentially have a .init section which would then break badly. Anyway, that constructor stuff is going to change, because we need to intercept constructors and run them from the dll entry point. I'm working on a patch to do that, which will hopefully solve your problem at the same time.
On January 3, 2004 06:39 pm, Alexandre Julliard wrote:
Anyway, that constructor stuff is going to change, because we need to intercept constructors and run them from the dll entry point. I'm working on a patch to do that, which will hopefully solve your problem at the same time.
Will this patch also remove the need for the wrapper for C++ programs? -- Dimi.
participants (5)
-
Alexandre Julliard -
Boaz Harrosh -
Dimitrie O. Paun -
Wim Lewis -
wiml＠underhill.hhhh.org