Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

dll linking problem

Pietro_P_
Beginner
516 Views

I have a solution with two projects: one outputs a dll, the other one the executable. The latter references some subroutines contained in the dll. They both output to the same directory. In "Project dependencies" for the executable i flagged the dependency on the dll, thus resulting in a building order dll->executable. DLL builds correctly alone AND OUTPUTS A .LIB FILE; instead, building the whole solution results in a linker error  LNK1181: cannot open .lib file, i guess simply because the lib file gets deleted before building process.

what am i doing wrong?

thanks for help

0 Kudos
12 Replies
Pietro_P_
Beginner
516 Views

I managed to build the solution correctly by deleting the .lib extension among the "extensions to delete on clean" for the executable project. Now the question is: is it the proper (and safe) way of doing it? i guess no, since there must have been a reason for the .lib extension to be in that list .

thanks

0 Kudos
Kevin_D_Intel
Employee
516 Views

With what you describe doing, the DLL’s import lib (.lib) file is being removed as part of the build process for the main program. I wouldn’t advise deleting the .lib extension and it’s probably better to allow each project to produce output files in unique directories.

There’s a really nice and helpful discussion on building DLLs in the Building Dynamic-Link Libraries topic in the Using Intel® Visual Fortran to Create and Build Windows*-Based Applications manual.

Let us know if that helps and if you have other questions.

0 Kudos
Steven_L_Intel1
Employee
516 Views

I always recommend against changing the projects so that they all output to the same location. This may be convenient, but as Kevin says, can cause serious problems when a rebuild cleans output directories. It is better to leave each project's output and intermediate directories alone and use project references to link in libraries as needed. You can use post-build steps to copy DLLs.

0 Kudos
Pietro_P_
Beginner
516 Views

Thanks. I set the dll output directory to $(OutDir)\dll\$(ProjectName).dll, and now it works. i guess the executable automatically reads from the dll project settings the new output directory and includes it, since I didn't have to change anything in its settings. Am i guessing correctly?

0 Kudos
Steven_L_Intel1
Employee
516 Views

If the DLL project is a dependent of the EXE project, then yes, by default the linker will include the "output" library of the DLL project.

0 Kudos
Pietro_P_
Beginner
516 Views

sweet!

thanks

0 Kudos
Steven_L_Intel1
Employee
516 Views

One caveat - this doesn't work if the dependent DLL project is a C++ project. In that case you will have to explicitly link in the export library from the DLL project.

0 Kudos
Pietro_P_
Beginner
516 Views

ok, thanks for pointing that out.

a couple of things more:

1)i write this line at the beginning of every procedure to be compiled as dll:

    !DEC$ ATTRIBUTES DLLEXPORT:: ["name of the procedure"]

is it mandatory?

2) is it better (i'm only interested in facilitating compiler optimization, nothing else) to have the interfaces of the subroutines in the dll declared in the executable?

0 Kudos
Steven_L_Intel1
Employee
516 Views

1) Yes, it is mandatory for procedures you want to be called by executables that use the DLL. If they're just procedures used internally to the DLL, you don't need that.

2) Explicit interfaces are always a good idea. The usual method is to have the DLL project produce a module that defines the interfaces. If your DLL consists of module procedures, this is pretty easy since you just need to provide the .mod. Submodules are also helpful here, allowing you to separate the interface from the implementation.

0 Kudos
Pietro_P_
Beginner
516 Views

sorry to go back to the main problem: the solution compiles and links just fine, but when i run it i get a message saying the dll is not present in my pc. again, what am i missing? i don't want to copy/paste the dll every time from where it's ouput to the .exe folder. is there a workaround?

 

0 Kudos
Steven_L_Intel1
Employee
516 Views

For your Visual Studio project you could add a post-build step that copies the DLL to the project folder, since that is the default directory when running the program from within VS.

  • Right click on the DLL project, select Properties
  • Select Build Events > Post-Build Event
  • Change Configuration to All Configurations
  • Change Platform to All Platforms
  • For Command Line, put in: copy $(OutDir)\$(ProjectName).dll ..
  • (Don't miss the .. in the command!)
  • For Description, put in: Copying DLL to executable project folder
  • Click OK

Keep in mind that if you want to run the program from outside VS you'll need to put the EXE and DLL in the same folder, or put the DLL some place else that Windows will find it (default folder or on PATH.)

0 Kudos
Pietro_P_
Beginner
516 Views

Steve Lionel (Intel) wrote:

For your Visual Studio project you could add a post-build step that copies the DLL to the project folder, since that is the default directory when running the program from within VS.

  • Right click on the DLL project, select Properties
  • Select Build Events > Post-Build Event
  • Change Configuration to All Configurations
  • Change Platform to All Platforms
  • For Command Line, put in: copy $(OutDir)\$(ProjectName).dll ..
  • (Don't miss the .. in the command!)
  • For Description, put in: Copying DLL to executable project folder
  • Click OK

Keep in mind that if you want to run the program from outside VS you'll need to put the EXE and DLL in the same folder, or put the DLL some place else that Windows will find it (default folder or on PATH.)

It works with a slight modification : i had to write "copy $(OutDir)\$(ProjectName).dll $(OutDir)\.."

I can see the end of this!

thanks a lot

0 Kudos
Reply