- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have a strange issue. Any assistance is greatly appreciated.
Project1: I link several routines with a DLL using
!DEC$ ATTRIBUTES DLLIMPORT, STDCALL, REFERENCE:: sub1
I compile and link usingAdditional Dependency to point to the mydll.lib file.
Everything is fine and it links and runs
Today, I create Project2, which is similar to Project1, almost a complete copy. I repeat all of the same switches and settings.
I compile and link, but now my external references get link errors:
error LNK2019: unresolved external symbol __imp_mysub@44
I can't find a solution
So I go back, and re-compile Project1. It now creates the same link errors. But I didn't change anything in the compiler/link settings. And yesterday it worked.
Any ideas?
...Brian
I have a strange issue. Any assistance is greatly appreciated.
Project1: I link several routines with a DLL using
!DEC$ ATTRIBUTES DLLIMPORT, STDCALL, REFERENCE:: sub1
I compile and link usingAdditional Dependency to point to the mydll.lib file.
Everything is fine and it links and runs
Today, I create Project2, which is similar to Project1, almost a complete copy. I repeat all of the same switches and settings.
I compile and link, but now my external references get link errors:
error LNK2019: unresolved external symbol __imp_mysub@44
I can't find a solution
So I go back, and re-compile Project1. It now creates the same link errors. But I didn't change anything in the compiler/link settings. And yesterday it worked.
Any ideas?
...Brian
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the directive you use sub1 but the error is for mysub. Which is it? When you paraphrase, you often hide important information that helps us help you.
If you use STDCALL by itself, the routine name is downcased, hence "mysub" rather than "MYSUB". I don't know which spelling your DLL library uses. The first thing I would do is a "dumpbin -exports mydll.lib" from a command prompt window and see what the spellings of the exported names are. You won't see __imp_ in the names shown there.
If you use STDCALL by itself, the routine name is downcased, hence "mysub" rather than "MYSUB". I don't know which spelling your DLL library uses. The first thing I would do is a "dumpbin -exports mydll.lib" from a command prompt window and see what the spellings of the exported names are. You won't see __imp_ in the names shown there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the confusion.
The issue is the __imp_ prefix, which as appeared for the first time. Why is __imp_ being prefixed and how do I stop that. I presume a compiler setting has beenset globally in Studio 2010 rather than for the project. Since the old Project1 now produces the same error.
...Brian
The issue is the __imp_ prefix, which as appeared for the first time. Why is __imp_ being prefixed and how do I stop that. I presume a compiler setting has beenset globally in Studio 2010 rather than for the project. Since the old Project1 now produces the same error.
...Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Compiler Settings:
/nologo /debug:full /Od /extend_source:132 /warn:interfaces /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:dll /threads /dbglibs /c
Link Settings:
/OUT:"Debug\prog2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"O:\Fortran\prog2\prog2\Debug\prog2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"O:\Fortran\prog2\prog2\Debug\prog2.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"O:\Fortran\prog2\prog2\Debug\prog2.lib" o:\fortran\prog1\prog1\release\prog1.lib
/nologo /debug:full /Od /extend_source:132 /warn:interfaces /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:dll /threads /dbglibs /c
Link Settings:
/OUT:"Debug\prog2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"O:\Fortran\prog2\prog2\Debug\prog2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"O:\Fortran\prog2\prog2\Debug\prog2.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"O:\Fortran\prog2\prog2\Debug\prog2.lib" o:\fortran\prog1\prog1\release\prog1.lib
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no compiler setting involved. The __imp_ is added whenever you use DLLIMPORT. It is not visible in the DLL or the export library directly, but if you're linking against an export library it will be used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great. Thanks. That helps. So, I can assume that my code and compiling is okay. Since Project1 was working but isn't now, and Project2 is set up the same. So the link error must be related to not finding the DLL on the path or local directory. I've tried various combinations with no joy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope - the DLL itself is not a party to this. It's all the .LIB. The DLL is not referenced until you run the program.
Please show the output of a "dumpbin -exports" on the .lib - do this from a Fortran Command Prompt window.
Please show the output of a "dumpbin -exports" on the .lib - do this from a Fortran Command Prompt window.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Arg, hah! andI've been programming for 25years! I hate stupid errors. Thanks for your help. It only does what you tell it. At the last minute, I created wrapper functions for the function calls, so that there wouldn't be issues with other code.It took two seconds to do while doing a billion other lines of code, and apparently a shorter timeto forget; I don't even recognise that I wrote the code, but its there. lol. So, my original function calls, which were working, now needed to call the wrapper functions. Since it was all debugged, I was convinced the issue had to be elsewhere. Classic. more coffee.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad to have helped.

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