.. I was wondering if there was anything to test yet?
We're stuck otherwise at:
eclipse$ $pd/wine sol.exe
/usr/obj/ports/wine-20040121/wine-20040121/loader/wine:/usr/obj/ports/wine-20040121/wine-20040121/dlls/ntdll.dll.so:
undefined symbol 'DllMain'
/usr/obj/ports/wine-20040121/wine-20040121/lo
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Will this patch also remove the need for the wrapper for C++ programs?
Hopefully yes, that's the whole point of the patch.
--
Alexandre Julliard
[EMAIL PROTECTED]
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 th
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 <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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, sinc
[EMAIL PROTECTED] (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 a
Alexandre Julliard <[EMAIL PROTECTED]> 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 c
[EMAIL PROTECTED] (Wim Lewis) writes:
> There *is* a section named .init, but any code placed there will
> be linked after the C function __init() in crtbeginS.c, and will not be
> executed because that C function returns normally. But the only
> thing that __init() does is invoke the functions po
Alexandre Julliard writes:
> The dll init routine needs to be in the .init section in order to be
> called first,
Isn't that what attribute((constructor)) does? It places a call to the
routine in the .so's initialization section, whatever that section is,
so that the routine gets invoked during
[EMAIL PROTECTED] (Wim Lewis) writes:
> Use the GCC attribute((constructor)) syntax for DLL initializer hooks
> if possible, instead of the inline-asm syntax.
The dll init routine needs to be in the .init section in order to be
called first, attribute((constructor)) is not good enough. Why doesn'
10 matches
Mail list logo
