SLIM vs SLINK64

Maybe this has been answered, but I cannot find the post if that is the case.

It appears that SLIM and SLINK64 operate a bit differently when it comes to creating libraries. I think this because the MAKE file that builds my 32-bit version will not build the 64-bit version even though the files are all the same, created by the same steps for compiling, library creation, etc. It is in the final link stage for creating the executable that I am getting problems

In SLIM, each OBJ file may contain multiple functions/subroutines. It appears that each piece (function/subroutine) is extracted from the OBJ file and made available to be linked in as separate entities. Stated another way, it is as if each function/subroutine had been separately compiled.

In SLINK64, each OBJ file retains the entry point name of every compiled function/subroutine. In this way, if one function/subroutine is required from the library, all the other pieces come with it. Stated another way, if routines A, B, C, and D are compiled a a single file, then a reference to 'C' will cause A, B, and D to also be loaded.

As a contrived example, I have a library with an OBJ file that was compiled with 4 routines A, B, C, and D. In a separate library, I have an OBJ file that was compiled with 4 routines E, F, G, and D. I am being told by SLINK64 that I have a duplicated name 'D' when the second library is referenced. This could only occur (logically) if the individual objects (functions/subroutines) are being kept together, not separated, thus causing the duplication.

Am I getting that correctly?

I'm seeing statements in the documentation that indicate a library cannot be created using SLINK64, only DLL's and EXE.

So, my 'libraries' aren't being treated as would a standard library in 32-bit, it would seem. That would explain the behavior, if the 'library' is just an appending of object files, and referencing that is just like loading an object file. Of course the symbols would be duplicated!

You can use SLINK64 to create static libraries. SLIM is for 32 bit static libraries. I suppose that it might work for 64 bit static libraries but it was written a long time ago and has not been updated for 64 bits.

Paul,

I did some poking around in the MAP files for the same program in each of the memory models and was able to confirm that the linking of the static libraries produced for the memory models differs. I think that tends to confirm that the libraries are (internally) constructed a bit differently

Those created by SLINK64 will include all the compiled functions, regardless of their use so long as one function in a OBJ file is used, while SLINK will search out the individual components of a larger compile and use those individually.

Because some of these un-called yet loaded routines have COMMON that is quite large, the executable has grown from 75 MB to 1,205 MB. Takes quite a while to load!

The reason I am 'poking' at this is that the main set of routines supports several other individually linked programs. They are now twice as large as they were under 32-bit (no major worry), with the one exception of the one that is 16 times larger!

Bill

As I recall, SLIM does not do anything clever but only concatenates the supplied obj files.

SLINK64 ought to be selective and this needs investigating.