ld, dlls, and windows libraries
Sun Feb 28 23:02:00 GMT 1999
Paul Sokolovsky <email@example.com> writes:
> MK> When DJ's excellent work on ld is released, you'll be able to do:
> MK> $ gcc -shared -o mydll.dll -mwindows --export-all foo1.o foo2.o
> Wow! How long to wait for this?
DJ is the person to ask.
> MK> The --export-all exports all the non-static symbols as done on most
> MK> Unix systems. If you want to restrict the exports, you have two choices:
> And what about implibs? Is there a chance that they will be produced
> with gcc too, so procedure and data exports will be properly
> distinguished? That's the thing which causes most pain with gnu-win32
> tools now, imho, - suffering an access violation when, due to automatically
> produced def, which treats all exports as code, some fucnction fetches jump
> instruction instead of data.
I'm not exactly sure what you're asking, but I'll take a stab at it.
Currently you can create implib with dllwrap directly when building the
$ dllwrap --implib libfoo.a [rest of command line]
DJ's new ld has the same option:
$ ld --shared --implib libfoo.a [rest of command line]
As for data vs code, that's a fundamental limitation of Windows32 DLLs;
you have to optionally tag data as exportable in the DLL and access it
via __declspec(dllimport) to get the correct code, otherwise you get
eg., when building a DLL:
int __declspec(dllexport) globalvar;
and when using the the DLL:
int __declspec(dllimport) globalvar;
The DEF file entry is however the same for code and data. You can also
add the DATA keyword in DEF file, but I forget exactly what the
The examples I distribute as part of dllhelpers package show how to do
data just as you would do for MSVC or other commercial compilers.
The thing to remember is that creating true shared libraries as one would
expect on most modern variants of Unix (eg., ELF) is just not possible on
windows32; Interix does it, but it is a very different beast.
If this is not what you're asking, please let me know.
More information about the Cygwin