Bertho Stultiens <[EMAIL PROTECTED]> writes:
> Indeed for all DLLs, but libwine.so is in principle no dll, but a
> collection of routines to support wine as a whole. Unless you want to
> introduce a special dll in wine?
No, libwine.so shouldn't be a standard dll, and ultimately it should
not contain much more than the dll loading code. But since now more
than half the code is in there I think it is worthwhile to make it
look like a real dll so that we can debug it; but this can of course
be done with an ad-hoc mechanism, it doesn't have to be done the exact
same way than we will do it for the real dlls.
> Oh, so you do not object to a wine-specific linker-script? I have been
> trying to keep away from linker-scripts because they are very
> non-portable. If you want linker-scripts, then I also suggest to include
> a separate resource section to keep them demand-loaded by the OS and
> have proper alignment guaranteed.
Well, I object on general portability principles, but if the
advantages are big enough (or the alternatives too ugly) I can
certainly consider it. I think building dlls will require some
advanced tools anyway (like objdump -L etc.) so a linker script is not
too bad, as long as linking statically remains possible without
special magic.
--
Alexandre Julliard
[EMAIL PROTECTED]
