I am building a 250K exe with dmc that can dynamically load a dll and find (and call) a function in it, using LoadLibrary and GetProcAddress. [The exe is a virtual machine for a dynamically typed language, so I can ask it in that language to do the aforementioned dynamic loading etcetera.]

I want the dll to call-back functions in the exe, and have had no trouble making that happen.

To this end I arranged that the exe is built using a module definition file that asserts the names of the symbols to be exported. The exe build also generates an import lib presumably containing these same symbols.

When a dll is built to be loaded dynamically by the exe, it is linked to this import lib, and that satisfies any references to calls back to the exe.

Only the functions in the dll to be called from the exe are annotated with __declspec(dllexport). None are annotated __declspec(dllimport). The dll has a DllMain function that merely returns true.

The recipe above works. Now for my problem.

I removed some of the symbols from the list to export in the module definition file used when building the exe. Now the map file from that build shows that a certain symbol that I did not remove from the module definition file is still being exported by the exe, yet that symbol is missing from the import lib generated in the same build, and compilation of a dll which uses that symbol fails because of "Symbol Undefined". This is all the more odd because a the symbol of an almost identical function is in the import library and links fine in the dll.

Is there a known bug that causes the linker to do this now and again?
Can anyone suggest a way for me to proceed, or indicate potential causes of my problem that I can investigate?

Any help appreciated.

Even worse: when I list the symbols in the import library using "lib -l", the symbol I need to link to is present!

On Tuesday, 2 October 2012 at 22:17:38 UTC, Carl Sturtivant wrote:
>
> Even worse: when I list the symbols in the import library using "lib -l", the symbol I need to link to is present!

That's what happened when I created the lib with implib using the module definition file, but I discovered such a lib won't link!

When I produce the implib as an option attached to the link command to build the exe, "lib -l" tells me the following no matter whether I use the older larger set of symbols in the module definition file or the new smaller set. This probably explains the erratic linking of the dll.

Error: Corrupt file 'ix.lib', Typ=x0, Len=x6308

So the linker is making a corrupt import library. Any ideas?

Solved the problem.

It seems that if there are more than 228 symbols being exported under the conditions of my first post to this thread (building an exe) then OPTLINK via the flag /IMPLIB:ix.lib produces a corrupt library that will not link all of the symbols. This corruption only becomes apparent to the DM library manager lib when there are a lot more symbols.

The only reliable way I found to build a working import library beyond 228 exported symbols is to use DM's implib utility on the executable file with the /system flag, and /noi for case sensitivity.

    implib /system /noi ix.lib ix.exe

The source is made up of C functions (not __stdcall) and the module definition file used for the link step contains each of their names without a prepended underscore as the symbols to export those functions, though the DM lib tool revealed that the linker saw those names each *with* the underscore prepended. Hence the /system flag to implib was needed to prepend those underscores before embedding those symbols in the import library.

On 10/2/2012 6:58 PM, Carl Sturtivant wrote:
>
> Solved the problem.
>
> It seems that if there are more than 228 symbols being exported under the
> conditions of my first post to this thread (building an exe) then OPTLINK via
> the flag /IMPLIB:ix.lib produces a corrupt library that will not link all of the
> symbols.

Please report this to bugzilla.

http://bugzilla.digitalmars.com/issues/