- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The win32 version of my static library works fine, but the x64 version crashes on a simple assignment of a passed in character string to a global character string in a module.
The main subroutine is in file modfull.f:
SUBROUTINE modfull(..........., dbpath)
USE ISO_C_BINDING
USE OoModtran
character*(*), intent(IN) :: dbpath
! other declarations
dataDirectory = dbpath <---- crash occurs here
!rest of code
END
The module is defined in file OoModtran.f90:
MODULE OoModtran
USE ISO_C_BINDING
IMPLICIT NONE
character*512 dataDirectory
SAVE :: dataDirectory
! other interface and function definitions
END MODULE
In 32bit version, dataDirectory is resolved and assigned the string. In 64bit version, dataDirectory can't be resolved and crash occurs on bad access attempt. I attached the project file for the library.
Thanks for any insight,
Dick
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
Steve,
Sorry about that, I was hoping there was just a bad setting or two for the x64 versions in the project file. I built a small test case, but it doesn't exhibit the problem. I was looking at the differences in the project files between the test case and my app. Inoticed that my app was using the dll runtime libs and not the static runtime libs. The Fortran code was originally set up to generate a dll that was used by a C++ dll. I couldn't get the x64 dll to load so I decided to try generating a static lib instead. The Fortran project property configuration type is grayed out in the dialog (unlike a C++ project) so I couldn't just change it from the dialog. I edited the vsproj file to change to a static lib andmust not havechanged the runtime library setting.
I went back to my project and switched to the static runtime libs. I generated a new static lib, but when I try to link it into my C++ dll, I get the following link errors:
1>Linking...
1> Creating library D:OpticksTAJ211CodeBuildx64DebugModFullModFull.lib and object D:OpticksTAJ211CodeBuildx64DebugModFullModFull.exp
1>libifcoremt.lib(for_diags_intel.obj) : error LNK2019: unresolved external symbol _iob referenced in function for__issue_diagnostic
1>libifcoremt.lib(for_nt_open_proc.obj) : error LNK2001: unresolved external symbol _iob
1>libmmt.lib(libm_error.obj) : error LNK2001: unresolved external symbol _iob
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __argv referenced in function for_rtl_init_
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __argc referenced in function for_rtl_init_
1>D:OpticksTAJ211CodeBuildBinaries-x64-DebugPlugInsModFull.dll : fatal error LNK1120: 3 unresolved externals
I wasn't getting these errors when using the dll runtime libs.
Thanks for any help - I'm getting so frustrated by this project I'm about ready to pitch the computer out the window and join a commune.
Dick
- 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
Steve,
Thanks. I went back to using the dll runtime libs and looked more into why the code was crashing on a simple assignment. I could see the contents of the global dataDirectory and the passed in dbpath in debugger. I could run LEN_TRIM on dbpath and get the correct string length. I could assign a local string into dataDirectory. When I tried TRIM on dbpath, I got a stack overflow. The light bulb went off - the subroutine interface takes way too many arguments (5 float*, 13 int, 7 float, 2 int*, 1 char*). The interface contains numerous pointers. Nobody ever bothered to stuff them into a structure and just pass the structure. I'm wondering if the 32 bit works ok and the 64 bit bombs due to the extra 4 bytes in each 64 bit address taking up too much stack space. The default is to use the stack for temp arrays. Does the operation of assigning one chararacter array to another use a temp array?
For a test, I commented out most of the parameter list and the assignment executed without a crash.
Is the best method to define the structure in a module and then just use the module to expose the definition in the subroutine interface block?
Thanks,
Dick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this character variable imported from a DLL? Since it is a mixed-language application, are you sure that all address objects are declared the proper size?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page