In a completely different direction, we could potentially
solve this problem by defering the gcc generated ctors invocation
until Wine loaded the dll.
That is, if we stubbed out the .init code from libmfc42.so
by defining an _init function that only did the BUILTIN_Register_DLL,
then ld.so would no longer invoke the MFC constructors
at library load time. We'd have to do some footwork to be
able to call the ctors list when Wine loads the library, but
that wouldn't be too hard.
This is, I believe, basically Bertho's solution, only accomplished
in a slightly different fashion.
However, the more I think about this, I think that the whole approach
I've proposed is, at this time, inferior to Alexandre's proposal.
The deciding point for me was to realize that glibc and ld.so
are, shall we say, less than perfect. Specifically, ld.so does
breadth first initialization, without any sort of dependency
analysis. Thus, you end up futzing with link orders in order
to be sure of correct library initialization orders. This is a
nasty trap for newbie programmers to have to avoid; my whole
argument hinges around making life better for newbies.
In fact, Wine supplies superior library loading and intialization
than glibc and ld.so do.
So, for me to assert that Wine should rely upon the OS for library
load and initialization, when the OS is at this time, broken,
is perhaps not wise.
Now, glibc 2.2 is supposed to include a dependency analysis
process.
I'm going to propose a modification to glibc: to allow
an initialization function other than _init, with
hooks to allow us to call back to the original _init
and/or the handy __do_global_ctors_aux() function.
Does anyone know which list is best for discussing such
a proposition? I follow glibc-linux, but it's a pretty
low traffic list.
Jeremy
Eric Pouech wrote:
>
> > > I suppose - but it feels wrong to build a winelib app foo, and
> > > end up with a 'foo' and a 'foo.so', where there's no real code in
> > > 'foo'.
> >
> > I can't agree more! I keep wishing I could think of a better
> > reason than that though. Alexandre has this annoying habit of
> > making decisions based on practical things, rather than either
> > your or my high moral standards <g>.
> well, from what I can see, except for the .so lib name, the 'foo' exec
> shall be the same for all winelib apps (in the Alexandre's approach)
>
> we could in that case, only build for a winelib app only a foo.so file,
> and symlink the foo exec to a winelibexec program
>
> when started this winelibexec program would get in argv[0] foo as
> exec name, so winelibexec could decide to load (lib)foo.so file
> and get the WinMain entry point from it
>
> just my 2 cents
>
> A+
> --
> ---------------
> Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
> "The future will be better tomorrow", Vice President Dan Quayle