when loading obj GetExternalModuleAddrEx() gives me "__divull" as unref function

[Zergios26]

Dear forum,

I've got a new problem and was not able to solve it so far.

I am using a software which load / unload ".obj" labwindows/Cvi files 

for one of these objects, I cant because of an error: during the GetExternalModuleAddrEx() the status returned is -5 : unreferenced address. and I cant figure out why?

The buffer return "__divull" as the name of the unreferenced function but I dont have such a function in the obj file.

Is someone having an idea ?

Best regards,

Serge 

[Zergios26]

Hello,

Finally, I have found the problem.

__divull is "division unsigned long long", meaning that my object was not linked with math extension.

maybe it is a limitation of the file.obj type or I don't know how to do. (there is no problem with the build and execution if the file.c is included in the host application)

Posted in case it could be usefull to someone else (I've spent some hours digging in the soft to found what __divull was) and if someone know how to link obj with math extension if it is possible.

Best regards,

Serge

[rolfk · Accepted solution]

An obj file is simply the compilation of the C code of a single C source file. Any external dependencies (library functions you use) are not part of the object file. Normally the linker to create an exe, dll or lib file will pull in all the dependencies. This means any project local object files, but also external dependencies although such dependencies are usually not linked in as individual obj files but instead as lib file, which is mostly a package of obj files.

So if you call a math function in your code and then try to load that obj file dynamically you have to make sure that the dependencies your module calls are already loaded at the time you try to load your own module. The LabWindows/CVI dynamic object file loading is a LabWindows/CVI specific feature that almost no other compiler supports (because DLLs or shared libraries provide a much more standardized way that solves all the problems dynamic obj loading was supposed to solve). But LabWindows originates from old DOS days where DLLs were totally unheard of. And it had to deal with a 640kB RAM limit. In order to get more complex measurement applications to even be able to load, it was very important to have a method of dynamically load specific modules at runtime. LabWindows for DOS implemented this by allowing dynamic obj file loading similar to what was also used in Turbo Pascal/Delphi at that time. It's a completely custom method which only was feasible since LabWindows already had a compiler and linker built in to create the actual binary executable code, so reusing that for dynamic loading of binary modules wasn't that a terrible task to develop.

When it was ported to LabWindows/CVI to run on Windows the LabWindows/CVI developers retained that ability for backwards compatibility, even though it was technically superseded by the well established and much more standardized Windows DLLs.

[Zergios26]

Thanks a lot Rolfk, for these precision.

Best regards

Serge