Solution(never tried):

What I like(in my app(c)):
__dllexport CFunction(int arg)
//implementation here

Def file:

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!

On 2/27/06, Michael Gerdau < > wrote:
> 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.

Or so.

HTH, best,
Vote against SPAM - see
Michael Gerdau       email:
GPG-keys available on request or at public keyserver