- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have some calls to GETDAT, GETTIM, etc in my subroutine. During linkage with 9.0 I get unresolved externals (I have libifport.lib in the LIB env. var):
error LNK2019: unresolved external symbol _GETDAT@12 referenced in function _WRITIT
error LNK2019: unresolved external symbol _GETTIM@16 referenced in function _WRITIT
error LNK2019: unresolved external symbol _GETTIM@16 referenced in function _WRITIT
The problem goes away if put in a "use IFPORT" at the top of the routine. However this code still has to compile under CVF. How do I fix the unresolved externals without putting in code the CVF can't understand?
Adrian
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think you'll have to bite the bullet and either use standard Fortran calls (you should never use a compiler which doesn't have DATE_AND_TIME()), or set up so that you have
USE IFPORT
when compiling with ifort and
USE DFPORT
or whatever, when using CVF. Or, a last resort, if the declarations are consistent between CVF and ifort, copy them into your source.
USE IFPORT
when compiling with ifort and
USE DFPORT
or whatever, when using CVF. Or, a last resort, if the declarations are consistent between CVF and ifort, copy them into your source.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
use DFLIB still works in ifort, so I just put that in.
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your project was likely converted from CVF and thus had the "use CVF calling convention" option set. If you just call GETDAT without using the module, you'll get a call with STDCALL conventions that doesn't link. With default conventions, it should link.
I do agree that using DATE_AND_TIME is a better option, overall.
I do agree that using DATE_AND_TIME is a better option, overall.
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