• Carl Sturtivant (33/33) Oct 02 2012 I am building a 250K exe with dmc that can dynamically load a dll
• Carl Sturtivant (2/2) Oct 02 2012 Even worse: when I list the symbols in the import library using
• Carl Sturtivant (10/12) Oct 02 2012 That's what happened when I created the lib with implib using the
• Carl Sturtivant (19/19) Oct 02 2012 Solved the problem.
• Walter Bright (3/8) Oct 16 2012 Please report this to bugzilla.

"Carl Sturtivant" <sturtivant gmail.com> writes:

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.

"Carl Sturtivant" <sturtivant gmail.com> writes:

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

"Carl Sturtivant" <sturtivant gmail.com> writes:

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?

"Carl Sturtivant" <sturtivant gmail.com> writes:

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.

Walter Bright <newshound2 digitalmars.com> writes:

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/