exec-shield workaround take 2

[Mike Hearn]

On Sun, 11 Apr 2004 02:20:16 -0700, Dan Kegel wrote:
> This isn't all bad.  Consider: we could add the ability to load
> PE executables and shared libraries into this private ld-linux.so.

I think that would be a very bad idea, frankly. The real glibc rtld is
huge. We do *not* want to maintain a dynamic linker along with the rest of
the codebase. This kind of preloader doesn't do dynamic linking itself you
understand: it is simply a "proxy" linker, which invokes the real one.

> At that point, the need for winelib executables to be shared
> libraries goes away, doesn't it?

Not really, it's more complex than just dynamic linker stuff. We need to
initialize the whole Wine environment before passing control to the app. I
think it could be possible to fiddle this anyway with alternate entry
points and stuff so you can type ./myapp instead of wine myapp.exe.so

> And that would make everybody very, very happy, as it would
> solve the problem that made mono and everybody else fork wine
> just so they could load Windows DLLs into native linux apps.

No, it would not solve these problems, which are mostly related to
setting up the Win32/Wine environment on the fly and have not much to do
with the dynamic linker.

Paul Davis has been doing some good work on this lately - it seems a
workable solution is in sight. At least for now Mono have something they
can use which doesn't require forking Wine.

thanks -mike