Working in Visual Studio 2013 Professional and I have been trying to debug old code from a VC++ 6 Project. When running the scripts, the error :
Error LNK1104: cannot open file 'DFOR.lib' Visual Studio
Come up. I have tried looking into the issue and it seems that the directory needs to be added in the the project properties, however, I have had trouble finding the directory in my computer. It also does not seem to be on my Companies computer I have been using but I have had trouble finding how to obtain it otherwise.
If you could help me find the DF98 directory (which is what others seems to have used) or help me otherwise, I would appreciate it greatly.
A short file name isn't much to go on but a quick search suggests that DFOR.LIB may have been part of Compaq Visual Fortran in the distant past.
I'm not familiar with that product but it seems to have been taken over by Intel at some point. You could try asking your question in the Intel forum for Intel® Visual Fortran Compiler for Windows* or read some of the relevant posts there already.
On a more general note the documentation for LNK1104 offers some discussion of possible causes and solutions to this error.
At this point you should not assume you need to find DFOR.LIB, you need to figure out why the linker is trying to open it.
Unnecessary LIB File
For example, an unnecessary #pragma comment (lib...) statement or erroneous linker command in your build might cause the linker to try and read DFOR.LIB even if it isn't needed to complete linking your code file.
In that case, the solution would be to delete (or comment out) the unnecessary #pragma comment (lib...) statement or remove the DFOR.LIB reference from the linker command and rebuild your project.
In Visual Studio, the likely place to find an unnecessary LIB file reference is in Project Properties | Linker | Input in the "Additional Dependencies" property. When changing this property remember to do so for all configurations and all platforms (not just Debug & Win32). For a make file or other command-based build linker input files are listed one at a time in the linker command without a specific switch.
A second place you might find an unnecessary file reference is the Linker's /DEFAULTLIB command. There is no specific Visual Studio property corresponding to this switch but it can be specified in the Command Line property.
Required LIB File
On the other hand, if the linker is reading DFOR.LIB to resolve some reference then you need to figure out what part of your code is causing DFOR.LIB to be required.
In the simple case your code is directly calling a function implemented in DFOR.LIB which the linker is trying to resolve. The linker's list of unresolved references might help you figure out the function name.
In the less simple case your code might be calling a function in some other library file which in turn calls a function (or functions) in DFOR.LIB.
In both cases the linker /VERBOSE and /FORCE options may help you gather more data.
Once you know which part of your code results in the need to link to DFOR.LIB you can decide what to do about it.
You might rewrite the code to use a different function in some package you do have access to
You might find a more modern (and supported) implementation of that function - in Intel's Visual Fortran implementation for example
You might find a licensed copy of Compaq Visual Fortran (and hope that it still runs on modern systems)
You might find that Visual Fortran is a red herring and that your DFOR.LIB comes from some completely different package
Related
I use Visual Studio 2013 to make a CLR-compatible version of my C++ code library ('mylibrary.lib'). It's been working fine for years, but all of a sudden I'm getting 'LNK1104' errors because Visual Studio is looking for 'mylibrarymdd.lib'.
Why is it suddenly, magically tacking on 'mdd' to the library name instead of using the .lib file I specified? And how do I get it to stop doing this?
I've found two workarounds for this problem, but don't like either one of them. Hopefully someone is able to explain why these steps were unnecessary and then all of a sudden necessary.
The first and most obvious work-around is to modify the dependency's project settings so the target output filename matches what the consuming project is expecting -- namely, 'mylibrarymdd.lib'.
The second work-around is to use "/NODEFAULTLIB:mylibrarymdd.lib". This is required for every individual dependency with the auto-naming issue.
To get to the correct (IMHO) solution, one would need to know WHY Visual Studio is creating a "default library dependency" of 'mylibraryMDD.lib' in the first place. As I stated, it wasn't doing so before and there have been no recent updates to Visual Studio or the project files themselves.
I did find that there was a change to a dependency of 'mylibrary'. It pulls in the static OpenSSL libraries and those were updated. It's unclear how that would cause the above behavior, however.
I created a new solution for zlib 1.2.7, set it up as a static library, added the necessary headers and source files from ./zlib/contrib/minizip and got it to compile just fine. I then linked it against libpng (also as a static lib), which also compiles fine. Then, I linked libpng to my graphics engine project (also a static library)... still no errors.
But as soon as I link my main project to my graphics engine, I get several LNK2026 errors regarding crc32.obj, deflate.obj, inflate.obj, d3dxplane.obj, d3dxvec4.obj and other zlib/directx related modules. It's telling me that they are coming from my graphics engine lib, so I've decided to fix this by adding /SAFESEH:NO to my linker flags for the corresponding projects.
NOTE: I should probably state that all projects are set to target x86, NOT x64.
The problem, however, is now I'm getting:
warning LNK4044: unrecognized option '/SAFESEH'; ignored which results in the same LINK2026 errors in my main project.
If I open up a visual studio command prompt and type LINK /? it confirms that /SAFESEH is a valid linker option. I get the same error when I use /SAFESEH (without the ':NO'), and if I omit it entirely then my main project simply refuses build.
What's going on here? How do I get around this?
by adding /SAFESH:NO to my linker flags
Well, you mis-spelled it. Maybe in your question, maybe in the linker settings, the kind of coincidence that tends to explain why something that should work doesn't work.
It is available without having to type it in, do favor doing it that way. Project + Properties, Linker, Advanced, scroll down the right panel, "Image has Safe Exception Handlers" setting. Use the combobox to select No.
A quick google shows this indicates you need to recompile the offending modules with appropriate compiler settings.
Note that this flag is only works for x86 targets. If you're targeting 64-bit, you'll get this error regardless.
Also, from http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.80).aspx, which may be relevant:
The most common reason for the linker not to be able to produce an
image is because one or more of the input files (modules) to the
linker was not compatible with the safe exception handlers feature. A
common reason for a module to not be compatible with safe exception
handlers is because it was created with a compiler from a previous
version of Visual C++.
It would be helpful if you provided version numbers of your compiler, and how your copy of zlib was built (did you build it yourself, and if so, with the same compiler?).
In Visual Studio 2017
Right click on Project -> Properties -> Configuration Properties -> Linker -> All Options ->
Image Has Safe Exception Handlers = No (/SAFESEH:NO)
I'm wondering if bscmake is still needed for Visual Studio 2010 C++ Projects using unmamanged/managed code.
My understanding of bscmake is, that it is generating browse-files for each cpp-file in order to be able to use things in visual studio like the "class view" or "go to definition",...
But after asking a question about bscmake myself and reading other similar questions I was unsure what bscmake is for and why you should use it.
References:
How to get rid off “BSCMAKE error BK1500: Internal error” compile errors
LINK : fatal error LNK1000: Internal error during BuildLibrary
So my question is:
Is there any need to activate bscmake?
Advantages/Disadvantages activating bscmake?
bscmake seems no longer be supported for VS2010, see this bug reports:
Per-project Browsing in VS2010 and BSC files cannot be used.
So you can speed up your compile times by turning off the creation of SBR/BSC files,
as they are useless anyway.
BSC files had the big advantage that they could be used to browse external libraries which
were not part of your solution (MFC for example). This seems not be possible with
intellisense. I personally use VisualAssist as a replacement (which works quite well for me).
The intellisense does not need the browse information, it is used for object explorer which I have never used or needed to : http://msdn.microsoft.com/en-us/library/kbs280h1%28v=vs.80%29.aspx
The main disadvantages are longer builds, build errors due to being unable to build the bsc files.
The main advantages are you can view more information of your classes and objects and apparently they have added some feature called 'live browsing' since VS2005 http://msdn.microsoft.com/en-us/magazine/cc163658.aspx.
However I have to say that the intellisense has worked fine for me, plus I use VisualAssist and I have never needed the object browser and find that the additional compilation time and build errors is so frustrating for large solutions that I never have this switch on.
Using visual studio 2008 SP1,
This line:
LINK : debug\XXXXX.exe not found or not built by the last incremental link; performing full link
appears every single time I compile the project, no matter how small a change I make.
What could be the reasons for that?
Old question, but just in case for someone it is still an issue (and it is..).
Incremental link is incompatible with generating manifest file (Proj opts > Linker > Manifest File > Generate Manifest: Yes). Indeed, generating manifest modifies exe/dll so linker has to do full linkage.
There are some workarounds, for more details:
http://chadaustin.me/2009/05/incremental-linking-and-embedded-manifests/
Temporary (and easiest/fastest) solution is to disable manifest generation during development and enable it again in the release stage. Although this disables XP/Vista-style gui for the app (controls look like in "classic mode").
So it turns out that the problem fixes it self if I add /INCREMENTAL to the linker command line. This in spite the fact that the default behavior according to the docs is to enable incremental linking.
Strange.
Really shooting in the dark but,...
Do you move the XXXXX.exe from where it is built to somewhere else? The whole point of an incremental link is to change an existing exe. If there is none, it will be difficult...
Another possible reason is that the file was changed after the build (probably by another tool)...
All the reasons are listed in the help item for /INCREMENTAL:
Additionally, LINK performs a full
link if any of the following
situations occur:
The incremental status (.ilk) file is
missing. (LINK creates a new .ilk file
in preparation for subsequent
incremental linking.)
There is no write permission for the
.ilk file. (LINK ignores the .ilk file
and links nonincrementally.)
The .exe or .dll output file is
missing.
The timestamp of the .ilk, .exe, or
.dll is changed.
A LINK option is changed. Most LINK
options, when changed between builds,
cause a full link.
An object (.obj) file is added or
omitted.
An object that was compiled with the
/Yu /Z7 option is changed.
Download procmon from Microsoft.
Run it, set up a filter so that you are looking for accesses to the path that contains your .exe name.
Do a link.
See what trouble it's having -- does it find it, does it log an error on opening it. Procmon will log every single file open, read, close, etc. If it gets an error, it will log it.
Also make sure it can find the .ilk file -- I think it needs that as well.
(ALso in the dark) One possible reason is that you use a project-wide header referencing the __DATE__ macro. But in that case, you'd see a full recompile as well (do you?)
In my case, I have got this error yesterday.
VS set code generation > runtime Library to Multi-threaded Debug DLL (/MDd) instead of Multi-threaded Debug (/MTd).
If i recreate new project this bad settings happens again. I manually switch to /Mtd, then no error happens.
What is the use of .map files VC++ linker produces when /MAP parameter or "Generate map file" project setting is used? When do I need them and how do I benefit from them?
A nice article on how to use map files for finding crashes.
http://www.codeproject.com/KB/debug/mapfile.aspx
Manually doing all this is very uninteresting.
I am not aware of any tools which can read map file and help in finding the crash location. If anybody knows please update us.
For embedded systems, map files are a lot more useful. (Although you wouldn't be using Visual C++ for that ;)
Things like knowing how close you are to running out of program/data memory, and what location a particular variable resides in, are important.
WinDBG uses .map and .pdb files to help debug crashes, when analysing .hdmp and .mdmp crash dumps.
Basically they map memory address offsets to functions and variables within the .exe (and/or loaded .dlls). Very useful in general if you need to figure out why a customer is upset. Even more useful when they prove it was not your fault.
The most useful way to debug "post-mortem" crashes is using WinDbg (Windows platform). Open it up, and open the crash dump. Then set the source path to point at the code (if you have it), the symbol path to point at your .map and .pdb and the image path to the .exe, and type "!analyse -v" in the command line. Now you have a full stack trace with lines of code and everything. Of course you need to have the correct version of the source code for the version of the exe's and DLLs you are debugging.
It's even better if you have the MS symbol server in the path, and if the full page heap was turned on or adplus was running. With ADPlus in particular you will likely have variable values captured as well.
Some favourite WinDbg resources of mine:
First stop :: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
Force load the symbols :: http://www.osronline.com/ShowThread.cfm?link=182377
Useful site :: http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/page/7/
You need them rarely, but they can be handy debugging some problems because they give information on the location of functions and data.
For example:
detailed information on all segments (code, data and other).
link line numbers to code
You can use map files for debugging tools.
Linker maps can be very useful in large projects when you need to track dependencies between compilation units and libraries. Typically, a linker will report a symbol which caused problems, and more often than not, a simple search for this symbol name won't return any results (or will return tons of false positives for symbols like read).
Without a linker map, the only option you have is to analyze all available source files (after preprocessing pass if macros were used, which is typically the case) and hope that you find the relevant spot.
Linker maps usually have a section called "reference by file/symbol" which tells you which object file was required by another object file of your project, and which symbol exactly was referenced.
I was once working on a project which had to be ported on a system without locale support. The linker was reporting "undefined reference to _localeconv_r" errors, which would have been a pain to track down by searching through the sources. Luckily, a GCC linker map file generated with -Map=output.map revealed all problematic functions with a single search.
amap cross-platform GUI tool allows you to examine MAP files produced by the GCC, Visual Studio and some other compilers. You can find out, for example, how much every source file and every external dependency contribute to size of your executable.