Archive keyword in slink/slink64

In the 32bit version when using the 'archive' keyword in an slk file it creates both a DLL and a LIB file. In the 64bit slink64 it only creates the LIB. We need both DLLs and LIBs as we have Fortran EXE accessing the DLLs and C++ DLLs accessing the LIBs. Short of running the same slk file with archive on/off, would it be possible to replicate the 32bit behaviour also for 64bit?

Thanks!

SLINK can create DLLs, static libraries and import/stub libraries. When creating two at once it is probably creating a DLL and the corresponding import library.

SLINK64 can create DLLs and static libraries but not import libraries. If you need an import library for a given DLL then there is a Microsoft utility that will create an import library from a given DLL.

Please provide details of the kind of library that you need (and why you need it) and then I can look up the details. The documentation may already tell you.

I have noticed that the usual

extern 'C' FORTRAN_ROUTINE();

works with the lib created from slink, but not if I create it manually (see below). So in that case I need to use LoadLibrary in the C++ program to access the Fortran DLL, and this is what I am doing in the 64bit world.

This is what I use to create the .lib from the dll and it is much smaller than the one created by Silverfrost (which cannot be used with extern 'C' in 64bit)

@echo off
if '%1'=='' goto blank
call del %1.def
for /f 'usebackq tokens=4,* delims= ' %%i in (`dumpbin /exports '%1.dll'`) do  (
rem     echo %%i_%%j >> %1.def
        echo %%i >> %1.def
        )
call more +9 '%1.def' > '%1.def.new'
move /y '%1.def.new' '%1.def' >nul
copy %1.def temp.def
echo.EXPORTS>%1.def
type temp.def>>%1.def
del temp.def
lib /def:'%1.def' /out:'%1.lib'  /MACHINE:X64
goto DONE
:BLANK
echo No DLL file name present
:DONE

Addendum: It is of course possible to use /MACHINE:X86 for 32bit, but I wasn't able to get it work with extern 'C'.

So my advice is:

1. 32 bits: use dll and archive in your slk, and then extern 'C' will see the exported functions
2. 64bits: use only dll keyword in your slk, and the script above (eg. 'libcreate.bat fortranlibrary' without any extensions). Then extern 'C' will see the exported functions.

StamK

Your reply raises another issue but the first and primary question remains. Why do you want a .lib file? How do you use it when you have it? In other words, do you want a static library or an import library? There are two kinds and they are different and have different purposes.

StamK

Some background information...

A static library is basically a repository for object code. Think of it as a number of .obj files concatenated into one file. You can use it at link time when building multiple applications each of which make use of the library code. This object code is copied into the application at link time.

On the other hand, an import library is like a cut down DLL. It contains the same information as a DLL but only the 'headers' and not the executable parts. It contains the information that a linker needs when linking the corresponding DLL.

Some third party linkers use only import libraries when linking DLLs.

SLINK can create and use an import library if there is one but it does not need it. It can use the corresponding DLL instead.

SLINK64 does not create import libraries and does not use them. It uses the DLL itself, using the 'header' parts without copying the executable parts into the application.

Thanks Paul for the detailed reply. In C++ I am calling a Fortran routine via the extern 'C' route. I am specifying the fortran.lib in the linker configuration of Visual studio.

In 32bit:

1. If I use the lib created via the archive command, then C++ works fine.
2. If I use the script above (modified for 32bit) applied to the fortran DLL, then C++ CANNOT find the routine (even if I include the dll in the same folder).

in 64bit:

1. If I use the lib created via the archive command (and DLL in the same folder), then C++ does NOT work
2. If I use the lib created via the script above (and DLL with it), then C++ works fine.

This is the situation at the moment.

StamK

I don't know why method 2 does not work for 32 bits.

Method 1 for 64 bits does not work because SLINK64 does not create import libraries (no matter what commands you use).

I will check the documentation for SLINK 'archive' to see if SLINK64 is doing the same thing as it should. But this will not help in your situation.

Detailed study of the SLINK documentation reveals that the 'dll' command (without 'archive') creates a DLL whilst the 'archive' command (without 'dll' but together with 'addobj') creates a static library.

But, to complicate things further, SLINK can be used with 'dll' and 'archive' together in order to create a DLL together with a third type of .LIB (perhaps unique to SLINK) that can be used as either a static library or an import library. In other word, it contains both the 'static' components and the 'import' components.

The static part of this third type of LIB is formed from the 'addobj' input whilst the import part is formed from the 'load' input.

Going forward, SLINK64 could be changed so that it issues a warning when 'dll' and 'archive' are used together (to say that you can't do that).

In the longer term, SLINK64 could be developed and given the ability to create (simple) import libraries (I will put this on this wish list) and maybe even a DLL and its import library in one session.

In the meantime, if you are using a third-party (say Microsoft) linker to link a 64 bit Silverfrost DLL, then it may be necessary to first create an import library from the DLL. For Microsoft, this can be done via the Microsoft lib utility, as StamK has illustrated in his batch file above,

Many thanks Paul.

I have now added an addendum to my post about the script for future reference, feel free to revise if necessary. Thanks

Paul,

could you please tell me the Microsoft utility that creates an import library from a given DLL? For the INTEL 64 bit compiler ifort uses import libs to link against a shared library and somtimes I need to search for an implib when I have the corresponding dll at hand.

Thanks, Dietmar

Dietmar ,

just use my script from above, it should work as long as your path can find dumpbin and lib.exe.

The Microsoft lib.exe is in the Visual Studio tools. I don't know if it can be downloaded separately.

For libname.dll the command line is...

lib /def:libname.def /out:libname.lib /MACHINE:X64

where libname.def is an input file containing a simple line-by-line list of the routines you want to export.

The instructions say that the command must be issued from a Visual Studio command prompt but presumably only because the PATH to lib.exe must be set.

I don't know if this will work for Intel.