Greg Turner gmturner007@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...