What I like(in my app(c)):
__dllexport CFunction(int arg)
compile this with gcc using the -Wl,--def-file=your_def_file -Wl,--out-implib=libApp.a flags
this will create a library: libApp.a which will allow you to link your dll back to your main application.
The reason dll's can't do this normally is because in the PE/COFF file format, a dll is an exe, except the flags tell Windows it is a dll file and it must contain an export table.
Hope it helps!
> Would there be any way around this behavior, like a g++/ld parameter
> option, environment variable setting, etc? (I'm guessing there is not,
> especially if this is a Windows-OS restriction, but I'm leaving no stone
> unturned.) As an aside: when creating the same library(ies)/DLLs (that
> require the resolve-all-symbols-at-link-time problem) as static libraries
> (.a files), there are no link-time symbol-resolution problems. So at least
> there's some "lazy linking" capability at least on some level.
I'm not quite sure I understand what you are after. However maybe
the following info does help you anyway:
When linking against a DLL the "usual" way is to use an importlib
(Note: gcc/mingw/ld supports directly linking against the DLL without
the need for an importlib; MS VC++ up to version 6 could not do that;
I don't know about MS VC++ version 7).
An importlib basically is a special lib that "claims" the corresponding
DLL does export (at least) the entries the importlib "knows" about.
Wether or not the DLL actually _does_ export those entries is not
checked during linktime. So in a way you do have some sort of lazy
linking as the actual resolving of references is done at runtime on
Windows as well.
Since you could create an importlib without actually having the DLL
you could (technically) achieve a similar thing as on Linux.
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: firstname.lastname@example.org
GPG-keys available on request or at public keyserver