Silverfrost Forums

Welcome to our forums

Trouble linking with DLL

26 Apr 2023 7:55 #30228

I'm getting an error 902 'Unable to read size of import symbols'. I have no idea what that means, nor how to fix it.

The DLL is being built by CodeLite. I have other DLL's built with this tool and MinGW compiler, and they do not have this problem.

I have attached a link to the DLL itself in case that might be of help.

Bill

https://www.dropbox.com/s/7aicvv8fw0cqhyi/dxflib_dll_normal%20-%20Copy.dll?dl=0

2 May 2023 3:23 #30255

I don't know if there is an issue with Plato or not, but here's what I had to do for the externally generated DLL to use it in Plato.

Plato creates a BuildLog file that contains the commands used to compile/link. Here is the file as created:

FTN95.EXE 'Z:\DXF_Decode\MAIN.for' /NO_BANNER /VS7 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /IMPORT_LIB 'dxflib_dll_normal.dll' /WIDE_SOURCE /FPP /CFPP /BINARY 'Release\Win32\MAIN.obj' slink.exe 'dxflib_dll_normal.dll' -OUT:'Release\Win32\DXF_Decoder.exe' @'Z:\DXF_Decode\link.lst'

Unfortunately, it does not link up OK. The errors are:

Linking... WARNING the following symbols are missing: dxf_circle_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) start_block_acad_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_solid_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_deinit_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) end_block_acad_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_symbol_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_line_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_ellipse_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) dxf_init_ftn95 Z:\DXF_Decode\Release\Win32\MAIN.obj (Z:\DXF_DECODE\MAIN.FOR) Creating executable: Release\Win32\DXF_Decoder.exe Linking completed.

However, the following (manually created) file compiles and links just fine.

FTN95.EXE 'Z:\DXF_Decode\MAIN.for' /NO_BANNER /VS7 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /IMPORT_LIB 'dxflib_dll_normal.dll' /WIDE_SOURCE /FPP /CFPP /BINARY 'Release\Win32\MAIN.obj' slink.exe -OUT:'DXF_Decoder.exe' @'Z:\DXF_Decode\link.lst' -rlo:'dxflib_dll_normal.dll'

The differences in the generated command lines are subtle. In Plato, in the Project description, I specified the Import Library. This worked with the compile, but not for the Link. I tried a number of different ways to specify the library and get the link step to work, but was not successful.

I only point this out in case that you might need to do some alternate language programming and need to use a DLL. In this instance, I was testing the interface and output products. Using the DLL for 'production' is not done in Plato.

2 May 2023 6:50 #30256

Bill

The error report comes from the linker SLINK.exe. A linker can't process all DLLs. In the case of SLINK, only those that are 32 bit DLLs and conform to the COFF standard.

2 May 2023 1:01 #30258

Paul, SLINK is used in both cases. And the second case works, I believe, due to the order of the arguments. I'd experienced this before when building my own MAKE files. Perhaps in the second case the -rlo was not required.

What I have found, and it makes sense, is that the arguments that contain files to be loaded/scanned are processed in the same order as the command line. Thus, in the Plato example, having the DLL show up first means it gets processed but because there is nothing that needs resolution, SLINK forges onward, processing the list of object files. And the DLL is never 're-scanned'.

Please login to reply.