I have a VS solution which contains two vfproj's. One for a main program and one for a LIB. I'm getting unresolved externals because the LIB doesn't seem to be getting linked with the EXE. What is the proper way to set this up? I'm using VS 2010. With an old version of vs with cvf I vaguely recall typing the LIB's name into a field somewhere in project settings. Is it still done that way today?
連結已複製
As far as I can see in my settings, once I make the LIB project a dependency for building the EXE project, then it gets included in the link.
For some other projects, where I have not included the LIB project in the solution, I have added the LIB file as one of the files in the project, and then it gets linked.
Regards,
David
"Ah, yes. I see!" said the blind man. I right-clicked the solution item for main, and selected "Dependencies", and check the items to be included. That seems to have done the trick.
I still After doing Rebuild All, I think I'm getting close, but I'm still getting a few 8284 errors about scalers being passed into array dummy arguments. I'm going back my other thread about that error.
I think it would be smart to follow your advice, Steve. In VS2010, where is this done?
Configuration Properties/Linker/Input/Additional Dependencies?
or maybe
Configuration Properties/Linker/Input/Add Module to Assembly?
Do you just name the LIB file? What about path?
Right now, the unresolved externals I don't understand are routines in lapack that are called from routines in umfpack. These are both LIB's in my solution, and in umfpack I've set a "dependency" to lapack (this is not really needed, correct?). And in my main I've got dependencies set to both umfpack and lapack.
In Compaq fortran, what I did was...
- Created a Library folder and put copies of all LIB files in there
- In Project Setting/Link/Input set an Additional Library Path to that folder.
- In Project Setting/Link/Input/Object/Library modules listed the names of all the LIB files separated by spaces.
The linker command line was the following. The target being built is xlrotofe.dll
kernel32.lib umfpack.lib lapack.lib util.lib src.lib /nologo /subsystem:windows /dll /incremental:no /pdb:".\Debug/xlrotofe.pdb" /debug /machine:I386 /out:".\Debug/xlrotofe.dll" /implib:".\Debug/xlrotofe.lib" /libpath:"C:\Users\Brian\Documents\F Drive\xlrotorfe cvf\LIB\debug" /libpath:""C:\Users\Brian\Documents\F /libpath:""C:\Users\Brian\Documents\F
I would think that a "solution" in VS 2010 should make this easier?
It would be Linker > Additional Dependencies. But if you have an all-Fortran project you don't need to do this. Microsoft broke the use of dependent non-C++ projects in VS2012.
All you would need to do is make the library projects a dependent of your Fortran DLL project. Everything else will be done automatically.
I still can't get it to work. I'm getting unresolved externals I wasn't getting with CVF.
The top level item in the solution is a fortran DLL, call it main.DLL. It calls routines in several fortran LIB's. I'm almost certain the unresolved routines are to ones my code is not using. But anyhow, they all appear to be umfpack.lib calling routines in blas.lib, but they are coming up as unresolved. In project settings for main.DLL I have dependencies set to both of these lib's. umfpack.lib also has a dependency set to blas.lib.
Can you think of any reason why I'm getting unresolved errors?
Well, since you migrated from CVF, there's a difference in calling convention between CVF and Intel Fortran, so if you didn't recompile ALL the sources with Intel Fortran under the same settings for External Procedures, you could get link errors. It would be helpful if you'd show the text of the errors.
Thanks, Steve.
Here are a few of the errors:
Error 9 error LNK2019: unresolved external symbol _IZAMAX@12 referenced in function _UMZ2S2 umfpack_.lib(umz2s2.obj)
Error 10 error LNK2001: unresolved external symbol _IZAMAX@12 umfpack_.lib(umz2f2.obj)
Error 11 error LNK2019: unresolved external symbol _IDAMAX@12 referenced in function _UMD2S2 umfpack_.lib(umd2s2.obj)
Error 12 error LNK2001: unresolved external symbol _IDAMAX@12 umfpack_.lib(umd2f2.obj)
I take it that the @xx stuff is old Compaq baggage.
umfpack.lib was "imported". The vfproj's for the others I made from scratch. I will check the calling conventions on all of them. I'll do that today if I can, otherwise probably next week.
I meant umfpack.lib was compiled from a CVF project imported into IVF (i.e. converted). For the others I made the IVF projects myself.
Anyhow, for umfpack.lib I changed Fortran/External Procedures/Calling Convention from CVF to Default (all the others projects are using Default), and that got rid of the unresolved external errors. Yahoo!
I'm almost ready to start running this thing. Before I can do that I need to install IMSL (I'm using a few of its routines). I have VS 2012, IVF & IMSL installed on my host system, and that works except debugging has weird problems that seem to be uncureable. So I am presently doing everything in a virtual machine with VS 2010 & IVF. Next I will install IMSL into that virtual machine and hopefully the license will allow that.
Thanks bunches for sticking with me. I don't know what I'd do without you.
That's what we're here for.
Be sure to read Configuring Visual Studio for using the IMSL* Fortran Numerical Library
