[...]
>
> It doesn't appear to be able to pass argc and argv until it actually
> loads the executable start code:
Hmm. We're using different versions; I can't find elf/boot1.c.
The code I've focused on (from glibc 2.1.3-15):
From elf/dl-open.c: (the _dl_init_next function returns
the DT_INIT ptr, if any)
/* Run the initializer functions of new objects. */
while ((init = _dl_init_next (&new->l_searchlist)))
(*(void (*) (int, char **, char **)) init) (__libc_argc,
__libc_argv,
__environ);
[...]
> To further confound things though, when I actually tried making
> a simple shared lib with an _init function, it *did* get argc
> and argv, but as you suggested, libc then went wonky because
> it didn't get initialized properly - note the line above that reads:
Now, that's odd, because I've just rerun through my samples,
and everything seems to work as I expected (I can do a getenv(),
which seems to be a good litmus test). I did notice when testing
with Wine that I had to go to some extreme lengths to
prevent libc from being loaded ahead of Wine (as reported by ldd),
which does cause disastrous results (but it always does).
[...]
> The _init thing is I believe fairly gcc/ELF centric. It works
> because the linker twigs that it needs to put a DT_INIT tag into
> the ELF headers, pointed to that function.
>
> > One advantage to Alexandre's method (let Wine run, do
> > a LoadLibrary(), GetProcAddress("WinMain"), start the app),
> > is that it is more portable.
>
> 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>.
Jer
