- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everybody,
I have beenworking in a VS 2008 solution that has many projects, some of whichare Intel Fortran ones.
Of the Fortran projects, some are not dependent on any other (M, N below), but the others do depend on other Fortran projects (A, B below). I mean:
Fortran_A --[depends on]--> Fortran_M, Fortran_N(which don't depend on anything)
Fortran_B --[depends on]--> Fortran_M, Fortran_N (which don't depend on anything)
All the Fortran projects are aimed to generate dlls.
I am only able to make it all work if I manually copy N.dll and M.dll to the A and B projects' output directory!
I have attempted many different configuration schemes, particularly the one depicted in:
http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-windows-build-intel-mkl-program-with-intel-fortran-in-microsoft-visual-studio/
With no success at all.
I wonder whether somebody could help me.
Thank you.
I have beenworking in a VS 2008 solution that has many projects, some of whichare Intel Fortran ones.
Of the Fortran projects, some are not dependent on any other (M, N below), but the others do depend on other Fortran projects (A, B below). I mean:
Fortran_A --[depends on]--> Fortran_M, Fortran_N(which don't depend on anything)
Fortran_B --[depends on]--> Fortran_M, Fortran_N (which don't depend on anything)
All the Fortran projects are aimed to generate dlls.
I am only able to make it all work if I manually copy N.dll and M.dll to the A and B projects' output directory!
I have attempted many different configuration schemes, particularly the one depicted in:
http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-windows-build-intel-mkl-program-with-intel-fortran-in-microsoft-visual-studio/
With no success at all.
I wonder whether somebody could help me.
Thank you.
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By "make it work" do you mean "get it to compile" or "get it to run". Given you are talking about copying DLL's, which presumably have been successfully built, I think you mean "get it to run".
The Windows OS has a well defined set and order of places that it looks in for DLL's - have a look at the online (for example) or VS provided documentation for LoadLibrary for more information. Early in the order is the directory that contains the executable (.exe file) for the process. Later in the order are the directories that are listed in the PATH environment variable for the process at the time the DLL's are being loaded. You need to put or build your DLL's so that they end up in one of these locations.
There are a couple of options, including:
- Change the output directory (project property under General > Output Directory) for the DLL project to be the same directory as for the EXE (so the DLL gets built "in-place"). This is what I do and I believe it is probably the easiest and most robust solution. You may prefer to change the output directory for the EXE at the same time to put it at the solution level in the directory heirarchy, as opposed to the project level that Intel Fortran uses by default (e.g. the output directory is set to $(SolutionDir)$(ConfigurationName), rather than just $(ConfigurationName) ). The only downside to this approach is that the linking stage for the DLL's and EXE's will also clutter the output directory up with manifest files and other droppings.
- Manually copy the DLL's across to the exe directory, as you have been doing. It may be easier to automate this using a post-build step or a separate "configuration" project. I use this approach for pre-built or third party DLL's.
- Explicitly set the PATH environment variable for the EXE to include the directories that contain the necessary DLL's - see the project property under Debugging > Environment. I would use this approach if I wanted to annoy those that have to maintain my programs after I had left the company.
Be mindful that having multiple copies of a DLL floating around on the DLL search path can result in lots of confusion.
The requirement to place DLL's so that they can be found by the operating system when loading the EXE applies for deployment of programs (ie. after they've been installed) as well - so this is not really a "dependency" issue for the compiler. Additional consideration may also be needed at this stage for the location and method of installation of the fortran runtime support DLL's.
The Windows OS has a well defined set and order of places that it looks in for DLL's - have a look at the online (for example) or VS provided documentation for LoadLibrary for more information. Early in the order is the directory that contains the executable (.exe file) for the process. Later in the order are the directories that are listed in the PATH environment variable for the process at the time the DLL's are being loaded. You need to put or build your DLL's so that they end up in one of these locations.
There are a couple of options, including:
- Change the output directory (project property under General > Output Directory) for the DLL project to be the same directory as for the EXE (so the DLL gets built "in-place"). This is what I do and I believe it is probably the easiest and most robust solution. You may prefer to change the output directory for the EXE at the same time to put it at the solution level in the directory heirarchy, as opposed to the project level that Intel Fortran uses by default (e.g. the output directory is set to $(SolutionDir)$(ConfigurationName), rather than just $(ConfigurationName) ). The only downside to this approach is that the linking stage for the DLL's and EXE's will also clutter the output directory up with manifest files and other droppings.
- Manually copy the DLL's across to the exe directory, as you have been doing. It may be easier to automate this using a post-build step or a separate "configuration" project. I use this approach for pre-built or third party DLL's.
- Explicitly set the PATH environment variable for the EXE to include the directories that contain the necessary DLL's - see the project property under Debugging > Environment. I would use this approach if I wanted to annoy those that have to maintain my programs after I had left the company.
Be mindful that having multiple copies of a DLL floating around on the DLL search path can result in lots of confusion.
The requirement to place DLL's so that they can be found by the operating system when loading the EXE applies for deployment of programs (ie. after they've been installed) as well - so this is not really a "dependency" issue for the compiler. Additional consideration may also be needed at this stage for the location and method of installation of the fortran runtime support DLL's.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi IanH,
I wish I could generate the dependentdll's configured to find the independent dll's in some relative path. But, of course, as you said, it is a matter of where Windows is gonna look for dll's. The issue has nothing to do with VS2008 itself.
Thank you very much,
Belmiro
You know those times when you'd prefer that yourself or someone else could be wrong, but they aren't?
I am in such a moment. I wish there were another solution, but I think you have throughly addressed the issue, and left no room for any alternate (sound) possibility.
I wish I could generate the dependentdll's configured to find the independent dll's in some relative path. But, of course, as you said, it is a matter of where Windows is gonna look for dll's. The issue has nothing to do with VS2008 itself.
Thank you very much,
Belmiro
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page