> > If we have a linker script we should be able to declare symbols
> > directly in there, which will make things somewhat easier.
>
> 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, the only reason I would consider submitting a linker script
for this would be because it will be enabled only by a configure
script. In fact, that configure option will enable some other
rather pernicious behaviors (like loading all symbolic info so
we can write out .DBG files for MS to use).
Also, correct me if I'm wrong, but the simplest way to
hack this with a linker script would be to (shudder) change
the .text segment to readwrite, because then the previous
suggestion (Andrews?) would work.
I'm going to take a stab at this with VirtualAlloc, in the
hope that ld.so will leave me a crach between .so load addresses.
(i.e. do a VirtualAlloc of the address immediately prior to
the load point of the .so).
That approach should work for my current target, the
Corel tree, which still uses the unseparated dlls. This is
an issue I only need to solve once Corel adopts the
(wonderful) library separation that Alexandre has implemented.
Thanks for the comments.
I'm still holding out hope that there may be a way
I can trick ld into doing this for me without resorting
to a linker script.
Jeremy
