Mixed language project dependencies

[dmor]

We're in the process of upgrading from IVF 11.1 on VS2008 to IVF Composer XE 2013. We have a large solution (200+ projects) with a mixture of C++ & Fortran DLL projects that have many dependencies between them. I understand that implicit linking of Fortran DLL projects with dependant C++ DLL projects using the project dependencies no longer works. I've moved to explicit linking of the dependencies using the 'Additional Dependencies' linker option as suggested, but this approach doesn't allow me to specify which are the dependant projects and hence the build order. If I leave the project dendencies in place, as well as specifying the explicit linkage, the link fails with messages like this:

1>------ Build started: Project: CLib2, Configuration: Debug Win32 ------

1> stdafx.cpp

1> CLib2.cpp

1> dllmain.cpp

1> Creating library C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\CLib2.lib and object C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\CLib2.exp

1> CLib2.vcxproj -> C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\CLib2.dll

2>------ Build started: Project: Fmain2, Configuration: Debug Win32 ------

2>Compiling with Intel(R) Visual Fortran Compiler XE 13.0.1.119 [IA-32]...

2>Fmain2.f90

2>Linking...

2>ipo: error #11018: Cannot open C:\WINDOWS\system32\C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.lib

2>LINK : fatal error LNK1104: cannot open file 'C:\WINDOWS\system32\C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.lib'

2>

2>Build log written to "file://C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Fmain2\Debug\BuildLog.htm"

2>Fmain2 - 2 error(s), 0 warning(s)

========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

How do I specify that the dependant C++ projects are built first?

Thanks

Dave

[Arjen_Markus]

Can you elaborate on the "implicit linking" you mention? As far as I can tell, defining the appropriate project dependencies should work fine, also in the case of mixed language programming. But you do need to have an acyclic dependency graph - that is: there should not be any dependencies that run up and down the project hierarchy. (I had that situation once where one project implicitly depended on parts of another project - only by trying to build it several times would it complete. It is time-consuming to find out where this is coming from, but the alternative is far worse.) Regards, Arjen

[dmor]

In VS2008 if you specified a project dependency it would be linked into project automatically, but according to the article below you need to explicitly provided the path in the Additional Dependencies field or include the library as a source file in the project. Neither of these options specify the project dependency and more importantly the build order. http://software.intel.com/en-us/articles/configuring-visual-studio-for-mixed-language-applications The projects have an acyclic dependency graph. Dave

[dmor]

I just spotted that I didn't mention that we are moving to Visual Studio 2012 at the same time - This is the critical piece of information - sorry! Dave

[Arjen_Markus]

Hm, we moved to VS 2012 too recently, but I was not subjected to the pains the migration caused - luckily. If I read the article correctly (well, I scanned it) it concerns the compiler's libraries, not your own. Regards, Arjen

[dmor]

These are the important sections: Configuring Microsoft Visual Studio 2012 or 2010 NOTE: In Microsoft Visual Studio 2010 and later, a C++ project will not link in a non-C++ dependent project library. If you are using a C/C++ main program with a Fortran static or dynamic library as a dependent project, you must explicitly provide the path to the Fortran library, (the .lib export library in the case of a DLL project), in the C/C++ project's Linker > Additional Dependencies property, or as a "source file" in the project. NOTE: In Microsoft Visual Studio 2010 and 2012, a Fortran project will not link in a C++ DLL dependent project. A C++ static library dependent project will be linked in. If your Fortran project has a dependent C/C++ DLL project, you must explicitly provide the path to the C++ project's DLL export library (.lib) in the Fortran project's Linker > Additional Dependencies property, or as a "source file" in the project. The article is talking about users projects/libraries rather than compiler libraries. Unfortunately the article doesn't mention anything about build order of dependant projects/libraries. Perhaps you are lucky enough not to have a mixture of C++ & Fortran dependant projects in one solution. Dave

[Steven_L_Intel1]

If you have the dependencies set correctly, the build order should be right. But the paragraphs quoted are quite important as Microsoft has removed functionality we depended on for VS2010 and VS2012.

[dmor]

Hi Steve I've used the sample 'Fortran-calls-C' as a template for my issue. I recreated two projects in VS2012 with the Clib as DLL. The first issue seems to be coming from the Interprocedural Optimization of the Fortran EXE. If I turn off IPO the first issue goes away. However I'm still left with this error: fatal error LNK1104: cannot open file 'C:\WINDOWS\system32\C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\DebugFmain2.lib' This is the command line for the linker (listed in the properties page of the project): /OUT:"C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\Fmain2.lib" /qnoipo C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\clib2.lib Any idea what could be causing the second linker error? Dave

[Steven_L_Intel1]

I can reproduce this problem - it seems that there is a bug in how dependent projects are linked in. Let me look at this further....

[dmor]

Hi Steve Have you managed to progress this any further? We're unable to upgrade to Visual Studio 2012 until this is resolved. Thanks Dave

[Steven_L_Intel1]

Not yet, sorry. But soon, I hope.

[Steven_L_Intel1]

This will be fixed in Update 2, I believe. The workaround is to open the Fortran project properties, select Linker > General. Set "Link Library Dependencies" to No.

[dmor]

Update 2 seemed to improve things. We've been able to reconstruct our multi-project solution over a couple of days. However we still had a issue linking that had to be worked around. I'm wondering whether this is an issue with relative paths.

What I saw was that when a Fortran project had a c++ project as a project dependency, trying to build the Fortran dll gives the following error:

 LINK : fatal error LNK1181: cannot open input file 'C:\Program Files (x86)\Release\Phases.lib'

 In reality the c++ project is creating the lib file in a folder c:\rms\mde\dev\..\Release\

 This didn’t happen if the project dependency was removed and the c++ lib file was added as an additional dependency in project properties -> linker -> input -> additional dependencies, unfortunately we couldn’t do that as we need to set project dependencies to get the build order right

 To work around this, the path of the lib file (originally ..\..\..\Release) in the c++ project had to be changed to $(OutDir)$(TargetName).lib, that is in:

Project properties -> Linker -> Advanced -> Import Library   

 This doesn’t have an effect on the actual location of the c++ lib file (it is still generated in the same place) but this way the Fortran project picks up the right path to look for the lib file.

Were we doing something wrong using a relative path?

Dave

[Steven_L_Intel1]

That reads like the pre-update-2 behavior.  I tried a test case I had which failed with Update 1 but it succeeded with Update 2. VS2012 does not allow Fortran to see the output library of a C++ dependent DLL project, so you'll have to add the dependency manually. However, Advanced > Import Library is NOT the place to do that. This specifies the OUTPUT location of an import library when building a DLL.  You want to add the C++ project's .lib under "Input > Additional Dependencies".

[SergeyKostrov]

I'd like to make a note ( sorry for a late response ). A path ( please see 1st post ) is Wrong in Essence: ... ...C:\WINDOWS\system32\C:\Data\MixedLanguage\MixedLanguage\Fortran_Calls_C\Debug\... ... There are two C:\ in it: C:\WINDOWS\system32\C:\Data\MixedLanguage\MixedLanguage\...

[dmor]

Sergey, the path in the first post wasn't created by us. I think this is part of the bug fixed in Update 2.

[dmor]

Steve, we are already adding the dependencies manually to our Fortran project using "Input > Additional Dependencies". Our issue seems with the use of relative paths (??) in the creation of the C++ import library. Things don't seem to want to link if we use a relative path for the library creation, but an absolute path works.

Dave

[SergeyKostrov]

>>...dependant C++ DLL projects using the project dependencies no longer works... In a solution ( created a long time ago ) with 36 VS projects and more than 130 configurations ( Debug, Release, Win32, x64, etc ) only relative paths are used and all libraries always found. Take a look at a next comment below. >>...Things don't seem to want to link if we use a relative path for the library creation, but an absolute path works... It should work. In example dependant libraries added as follows ( this is in case of a C/C++ project ): ... #ifdef _DEBUG #pragma comment ( lib, "../../Bin/Debug/TestLibD.lib" ) #else #pragma comment ( lib, "../../Bin/Release/TestLib.lib" ) #endif ... You should use a right number of ../ in a path. Relative paths are also used in two bat-files which are invoked in Pre-Build and Post-Build steps to copy headers and built DLLs to different directories ( BinDebug and BinRelease ).

[Steven_L_Intel1]

Remember that the default path is that of the project, not the intermediate (Debug/Release) folder.  You can use the macros such as $(IntDir) or $(ProjDir) to establish an initial path, and then use .. as needed from there.

[dmor]

I think the issue here is that the relative path is being converted to an absolute path using the wrong starting point. We specifed a relative path that doesn’t move back up the folder hierarchy (i.e. .\test) and the Fortran project tries to link the following library (unsuccessfully).

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\test\Phases.lib"

We will stick to using absolute paths as Steve suggested. The starting point for relative paths appears to be the IDE directory, instead of the project directory.

Dave

[SergeyKostrov]

This is a short follow up... >>...We will stick to using absolute paths as Steve suggested. The starting point for relative paths appears to be the IDE >>directory, instead of the project directory... Hi Dave, A VS project ( any, Fortran, C#, C++, etc ) is always referenced in some VS solution ( a file with extension sln ) and this is the starting point for a relative path. Once again, I used relative paths all the time ( for a very long time... ) and I didn't have any problems. I admit, that I spent lots of time to set all relative paths properly for all projects and configurations ( ~40 and ~150 respectively ).