- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
dfwin.lib, dfor.lib, libc.lib, dfconsol.lib, dfport.lib
I have the libraries the linker wants (from a computer that still has CVF 6.6c installed on it) and I added them into the project solution but this did not resolve the issue. It began to have duplicate definitions errors, between the CVF version of the file and IVF version of the file.
After ignoring all 5 libraries I get the following error below. To me it appears that the functions that PSWPTH is looking for are Fortran intrinsic functions and since this is legacy code these intrinsic functions must be from CVF.
Linking... Creating temporary file "RSP1.rsp" with contents [ /OUT:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"dfwin.lib" /NODEFAULTLIB:"dfor.lib" /NODEFAULTLIB:"libc.lib" /NODEFAULTLIB:"dfconsol.lib" /NODEFAULTLIB:"dfport.lib" /MANIFEST /MANIFESTFILE:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/EFPS6.pdb" /SUBSYSTEM:CONSOLE kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MACHINE:I386 "Debug/RSIDECNFG.obj" "Debug/PYGERA.obj" "Debug/fbxdrv.obj" "Debug/PyrolmLink.obj" "Debug/RSISPY.obj" "Debug/EFPSVersionInfo.res" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GUIlink.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\slmpsw\\lsapiw32.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\PASSWD.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GEN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\TLEX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\Flowsheet.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\SPYRO6.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\FIREBOX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\LMFAC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\CONVEC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\NLSECURE.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\KIN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\AUXILL.lib" "k:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\EFPS6_lib.lib" ] Creating command line "Link @"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\RSP1.rsp"" Link: executing 'link' EFPS6_lib.lib(Pyrolm.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _GETENVQQ@16 referenced in function _PSWPTH NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _for_f90_index@20 referenced in function _PSWPTH NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _for_len_trim@8 referenced in function _PSWPTH NLSECURE.lib(PSWPTH.OBJ) : error LNK2001: unresolved external symbol _for_len_trim@8 NLSECURE.lib(PSWPTH.OBJ) : error LNK2001: unresolved external symbol _for_len_trim@8 NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol __OtsMoveMinimum referenced in function _PSWPTH NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol __OtsFill referenced in function _PSWPTH NLSECURE.lib(PSWPTH.OBJ) : error LNK2019: unresolved external symbol _SPLITPATHQQ@40 referenced in function _PSWPTH K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe : fatal error LNK1120: 6 unresolved externals EFPS6 - 9 error(s), 4 warning(s)So I look into the static library containing PSWPTH.f and I see that it's using DFWIN and using DFLIB. I comment both of those out, recompile the *.lib file and reinsert it into the main project. I compile and get the following:
Linking... Creating temporary file "RSP1.rsp" with contents [ /OUT:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"dfwin.lib" /NODEFAULTLIB:"dfor.lib" /NODEFAULTLIB:"libc.lib" /NODEFAULTLIB:"dfconsol.lib" /NODEFAULTLIB:"dfport.lib" /MANIFEST /MANIFESTFILE:"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/EFPS6.pdb" /SUBSYSTEM:CONSOLE kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MACHINE:I386 "Debug/RSIDECNFG.obj" "Debug/PYGERA.obj" "Debug/fbxdrv.obj" "Debug/PyrolmLink.obj" "Debug/RSISPY.obj" "Debug/EFPSVersionInfo.res" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GUIlink.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\slmpsw\\lsapiw32.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\PASSWD.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\GEN9306.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\TLEX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\Flowsheet.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\SPYRO6.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\FIREBOX.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\AUXILL\\Release\\AUXILL.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\LMFAC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\CONVEC.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\NLSECURE.lib" "K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\KIN9306.lib" "k:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\EFPS6_lib.lib" ] Creating command line "Link @"K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Debug\\RSP1.rsp"" Link: executing 'link' EFPS6_lib.lib(Pyrolm.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _GETENVQQ@16 referenced in function _PSWPTH AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _GETMODULEFILENAME@16 referenced in function _PSWPTH AUXILL.lib(PSWPTH.obj) : error LNK2019: unresolved external symbol _SPLITPATHQQ@40 referenced in function _PSWPTH K:\\Pyrotec\\Software\\RSISimcon\\930680IVF\\RSIEFPSBASE\\Release\\EFPS6.exe : fatal error LNK1120: 3 unresolved externals EFPS6 - 4 error(s), 4 warning(s)I toggled DFLIB on and off. Now I get all 9 original errors regardless. Any help would be appreciated!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For example: GETENVQQ is in DFPORT.lib which is now IFPORT.lib.
I tried adding USE IFPORT to PSWPTH.f, recompiling the library, then recompiling the project with the library in it.
No dice, still the same 9 errors =(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The AUXILL.lib (which contains PSWPTH.f) is built using IVF from the existing source code. Then AUXILL.lib is used in other project which has also been updated to IVF.
This solution was working in IVF before but now I'm having these particular issues. It's frustrating that something would work 2 weeks ago then not work now.
Thanks for your advice!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Then I take that AUXILL.lib and add it into another *.vfproj. That's when I get these errors.
You must be right about the CVF/IVF mixing. I've just got to figure out where it's occurring. If AUXILL.lib is building properly then it must be something with the other *.vfproj....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Besides switching to dynamic linkage, as Steve said, you will probably have to try building everything with /iface:cvf until you can get the libraries remade. That still would likely fail if the required run-time functions are actually from CVF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How can the compiler complain about unresolved external symbol _GETENVQQ@16 (PSWPTH.obj) in one instance and then not complain about it in another instance?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(In #5 you say "What I don't get is how can AUXILL.lib compile and build fine...".
When you build a library the librarian utility normally just builds a simple archive of all the bits of object code that were generated from the source code in the project. The librarian utility (which on Windows is actually the linker moonlighting for some extra cash on the side) doesn't go through each piece of object code and make sure that it can satisfy all the various symbol references - in many cases that would defeat the purpose of building a library.
It is not until the final link stage (when the actual EXE or DLL is built) that the linker must resolve all the symbol references in the bits of object code that are being linked together.
So building a lib is not a sufficient test that all is well.
If you had two projects that were both generating EXE's (or DLL's), and one was failing while the other succeeded, then that's a different story, one that would explore differences between the projects.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a GUILink_lib that contains a header file and two C++ files.
In the GUILinkC.c file (under the GUILink_lib project) there is a function called GUIDay with code as follows:
/*
* Function name: GUIDay
* Description : In a multi-day run, this is called with the number of the
* current simulation day, starting at day 1. In a single day
* simulation, it must also be called with argument 1.
* Arguments I: int DayNumber - the number of the day.
*/
void
GUIDay(int DayNumber)
{
GUICurrentDay = DayNumber;
}
Then in the Fortran *.lib project, X_lib, there is GUILinkF.f which defines a subroutine GUIDAY that relays to the C++ function above, with code as follows:
C
C Function name: GUIDAY
C Relays to : GUIDay(int DayNumber)
C Description : Assign the number of the day currently being processed.
C Arguments : INTEGER*4 DAY - the day number of the current run.
C
SUBROUTINE GUIDAY(DAY)
IMPLICIT NONE
INTEGER*4 DAY
INTERFACE
SUBROUTINE GUIDAYC(DAY)
!DEC$ ATTRIBUTES C, ALIAS:'_GUIDay' :: GUIDAYC
INTEGER*4 DAY
END SUBROUTINE GUIDAYC
END INTERFACE
CALL GUIDAYC(DAY)
END
The project is set up as follows:
MainProgram (Fortran *.exe)
X_lib (Fortran *.lib)
GUILink_lib (C++ *.lib)
SlmpswC_lib (C++ *.lib)
The two C++ projects are added to the overall project by choosing Add New Project -> Win32 -> Win32 Project. These two static libraries are compiled first, followed by X_lib then MainProgram.
After compilation the linker has unresolved external symbols from the Fortran GUILink.f file to the GUILink.c file.
Any thoughts? I understand that in this new environment C++ and Fortran files must be compiled separately in different projects but that a solution can contain multiple projects in a user-specified order. I think I have set this up properly.
Is there an issue with the declaration calling convention?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perhaps this is what you have done - but rather than setting compilation order you should be setting project dependencies (for example, perhaps the MainProgram exe depends on X_lib). An appropriate build order is an outcome of having the dependencies set correctly, manual ordering beyond that is simply for build convenience. The process for setting dependencies is similar to that for build order (it is simply a different tab on the same dialog) - right click on a project in the solution explorer and select "Project Dependencies".
If static libraries are part of a dependency chain then you can also decide whether you want to archive all the subordinate libraries into one big library as part of the build step. To do this, in the project properties set Librarian > Link Library Dependencies to Yes (a similar Link Library Dependencies setting exists for Fortran exe's and dll projects, but it is set to Yes by default). If you don't do this, then the top level exe or DLL needs to explicitly have all the subordinate libraries in its list of dependent projects.
If you are using VS2010 and have C++ project that depends on a Fortran library, then you may (will?) need to explicitly list the name of the Fortran library in the linker properties of the C++ project.
The Fortran 2003 standard introduced new features into the language to assist with "inter-operating" between Fortran and C. If you use these new features, the source code connection between Fortran and C will be portable and considerably more robust. I'd rewrite your interface block to be:
[fxfortran] INTERFACE SUBROUTINE GUIDAYC(DAY) BIND(C, NAME='GUIDay') USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT IMPLICIT NONE INTEGER(C_INT), INTENT(IN), VALUE :: DAY END SUBROUTINE GUIDAYC END INTERFACE [/fxfortran] If the subroutine in that interface was renamed to GUIDAY, popped into a module that was then used where appropriate you could eliminate the need for your Fortran wrapper subroutine.
SUBROUTINE GUIDAYC(DAY)
!DEC$ ATTRIBUTES C, ALIAS:'_GUIDay' :: GUIDAYC
INTEGER*4 DAY
END SUBROUTINE GUIDAYC
END INT[fortran] INTERFACE SUBROUTINE GUIDAYC(DAY) BIND(C,NAME='GUIDay') USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_INT IMPLICIT NONE INTEGER(C_INT), INTENT(IN), VALUE :: DAY END SUBROUTINE GUIDAYC END INTERFACE [/fortran] ERFACE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Fortran part: exactly as you gave it.
The C function: Add to what you gave:
extern int GUICurrentDay;
The C main program:
[cpp]#include
[bash]T:lang> ifort /MD /O2 guiday.f T:lang> icl /O2 /MD uguiday.c guiday.obj guidayc.c [/bash] Results:
[bash]T:lang>uguiday GUICurrentDay = 123456789 GUICurrentDay = 987654321 [/bash]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Ian,
Oops, what I meant by compiling order really is Project Dependencies. I set up the solution such that the Fortran exe MainProgram is dependant on Fortran static library x_lib and x_lib is in turn dependant on two other C++ static libraries in the same project. I assume that the projects are compiled in order of dependency.
I'll check on the status of Link Library Dependencies and make sure it is set to Yes.
I am using VS2008 and fairly new to programming.
So what you are recommending are two options:
1)Modify the INTERFACE block as you suggest and see if that resolves the Fortran/C linking issue
2) I rename theFortran GUIDAYCsubroutine to GUIDay, and then instead of using an INTERFACE command, instead put the subroutine into a MODULE block, then use that MODULE as needed. What is the syntax for using a MODULE block?
Thanks for the help!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page