wine/ tools/winebuild/winebuild.man.in tools/w ...

[Alexandre Julliard]

Greg Turner <gmturner007 at ameritech.net> writes:

> I'm sure it's all quite evident to you and the other old-timers around 
> here, so sorry to be slow!  Also, if I'm asking you to write a novel, 
> just let me know what I need to read up on.  Thanks!!

The idea is to mimic the way import libraries work under Windows, so
that's what you should look into. Basically the Microsoft linker
doesn't know how to link directly against a dll, so to use a dll you
have to link against a "stub" static library that contains just a list
of the functions exported by the dll. Under Unix the linker knows how
to link against the same .so files that the dynamic loader uses at run
time, so there is no need for separate import libraries.

The benefit of import libraries is that it reduces dependencies in the
build process, because you can generate all the import libraries first
and then build the dlls in the order you like, since they no longer
depend on each other. This also allows circular dependencies between
dlls, a misfeature that Microsoft uses unfortunately.

The main drawback is of course that it's easy for the dll and its
import library to get out of sync and then you are in trouble, because
the functions that you found at link time in the import lib do not
exist at load time in the actual dll. The Unix way of having a single
library is much cleaner, but of course we don't expect Microsoft to do
things the clean way <g>

The actual implementation is a bit different between Windows and Wine:
under Windows the import library has to be in the standard library
file format that the linker understands (xxx.lib, or libxxx.a for
gcc), and it is generated from the dll .def file. Under Wine we don't
need a real library since everything is done inside winebuild without
involving the Unix linker, so we use the .def file directly and skip
the intermediate step of building a library object file.

Hope this helps...

-- 
Alexandre Julliard
julliard at winehq.com