Jon Griffiths jon_p_griffiths@yahoo.com writes:
- Functions exported by name only should not be given ordinal numbers
in the .def output, so that link.exe can fill up empy ordinal slots and create a valid export table. Not doing this leads to an incorrect export table without any warnings or errors during the build.
We use the ordinal to generate the proper hint in the import table, so this is not a good idea.
- We need the stub functions to be present in the final dll file, or
our ordinal functions cannot be accessed. This is because link.exe requires that all ordinals be present in order to generate a correct ordinal export table. This in turn requires that the .spec.c files compile correctly under msvc, in order to get the stub functions included in the link. However, we obviously don't need the pe header or export tables that winebuild generates, since link.exe (and any other PE linker, for that matter) does this work for us.
The .spec.c file must not be used on Windows IMO. If the MS linker is really that brain damaged then you'll need to make sure you have valid functions for all entry points, or use a better linker (mingw should work AFAIK).
- Several symbols are expected to be exported as private and by name
only, or they generate warnings when creating the .lib and .exp files for the dll. This requires identifying said symbols, and correctly generating and parsing the PRIVATE flag in .def files.
I'd suggest specifying that in the spec file instead of hard-coding the symbols in winebuild.
Also please try to split your patch, there are clearly different changes in there, it would be a lot easier to analyze them independently.