On Mon, 2003-04-14 at 04:45, Alexandre Julliard wrote:
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Many people need to link against very simple DLLs that are simple shared libs, no fancy PE features.
In fact, for a lot of uses I believe simply exporting LoadLibrary and GetProcAddress would be enough - it's often for things like codecs with few entry points. Doesn't need to be a part of the traditional build process.
It will be fairly complex, and will probably add a lot of different constraints, I'm not sure it would really be an improvement over winebuild. If you want a really transparent solution then it should most likely be done directly at the linker/ld.so level.
This could be doable.
BTW, I'm not very familiar with the various formats (ELF/PE), what would we be missing if we are to export to ELF? Resources come to mind, but I think we can export some sort of symbol to ELF that our Wine code would understand, so they may not be a problem.
ELF is actually very flexible, resources could be done in the same way they are in Windows just by adding a new section then reading it from itself using libbfd.
They will still be a problem, you'll need to redo the resource functions to deal with that. Other problems include at least ordinal exports
Offsets in the export table? Symbol mangling?
, separate dll namespaces,
Windows style symbol scoping will have to be added to glibc at some point anyway, we've looked into this quite extensively for autopackage. Solaris style grouping semantics are the mostly likely candidate, and I think it's reasonably close to DLL namespacing. If not, then again symbol mangling perhaps or an abuse of symbol versioning.
and initialization order. Then of course you have all the binary compatibility problems with module handles that don't point to the right structures etc.
If you really want to provide a seamless Unix source environment, you pretty much need to give up on full binary compatibility, and do something more like what TWIN was doing. But I don't think that's where we want to go.
TWIN?
Full binary compatability is far more useful agreed, but source compatability isn't that important for a lot of projects, in fact they usually dynamically load the DLLs anyway for codecs or .NET P/Invoke.
You don't need to be able to do -lgdi32, just -lwine then being able to load DLLs in the usual wine fashion and get entry points by name would be good enough for now, it'd certainly be enough for say mplayer and possibly mono as well.