Support for pkgconfig

[Mike Hearn]

On Mon, 2003-04-14 at 04:45, Alexandre Julliard wrote:
> "Dimitrie O. Paun" <dimi at 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.

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center