- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sweet!
thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page