I'm ready to release my *.exe and set the release build in virtual studio 2005, but I got a error like that:
mt.exe: failed to load file "..\release\hasm.exe" {_~0 BEL SUB EOT BEL v STX
the BOLD string with 3-characters are symbol that can not print in plain text, and I can't copy them from my working conputer, but I edited them in Notepad++, and I can see them, now I typed them in "plain" text(and ther is no space(' ') between them) and I hope you can emagin their shape.
the trick is that, I can compile my debug-edition and the *.exe works well, I have tried other project and used the same encoding and there is nothing happened -- everything goes well with the debug and release.
I think there was some unicode in the code(some comments are Chinese), but the compiler should not stand along with the code, there must be a syntax error or something else. Now, it's not a syntax error or a link error, is there any other possibilities---I mean in my code? and what exactly the mt.exe doing?
ps: I have seached for all my code, there is no "{_~" in my (C++)code, FML...
My guess is that the project settings for release got broken somehow. Compare all settings between the debug and release configs. If you can't find anything, it's probably something internal in the project. The best way to fix that is to create a new project in the same solution and add all your source files to it.
Hope this helps.
Cheers,
Sebastiaan
Related
I'm a long time VB programmer, and pretty good with c#, but I'm dumb as a brick when it comes to c++. But nonetheless, I need to build the source code for GraphicsMagick.NET, specifically for .net 2.0 if I can, to try to see if I can convert it to a fully managed dll, so that I can import it into Unity3D (who cares why I need to build it?).
Anyway, without posting the entire project here, I realize it might be hard for anyone here to know exactly what is causing my error. But perhaps someone can give an educated guess? Edit: you can download a zip of the full source from https://graphicsmagick.codeplex.com/SourceControl/latest if you want to see all the code I'm working with that is giving me this error.
This project, I assume, is supposed to compile without errors right out of the box. But it doesn't. It has this line of code in the include.h file:
# if defined(HasBZLIB)
# pragma comment(lib, "CORE_RL_bzlib_.lib")
# endif
and as a result of this evil line, I'm getting this evil error:
LNK1104 cannot open file 'CORE_RL_coders_.lib'
GraphicsMagick.NET.net20
C:\Users\A\Downloads\graphicsmagick-d\GraphicsMagick.NET.net20\LINK 1
Being the good VB programmer, I searched my project folder extensively, and that _.lib file doesn't exist. But in the process of searching online, I learned that c++ sometimes generates .lib files when you build a project. So perhaps this file was supposed to be built first, before it was linked, but for whatever reason it didn't get built first? You can see how clueless I am with c++.
Of course I commented out the line. But then it simply generates an error on the next line, which is another .lib file missing. I assume it will generate an error on every _.lib file in the entire include.h file, and there are a fair number of them.
Why is this project, which is supposed to build, missing so many .lib files? Can anyone give an educated guess why? am I probably missing some dependency that the author of this project forgot to mention in the installation instructions? Or would it be more likely that these .lib files are supposed to be created by me somehow, and I'm just not building it right?
In the downloaded release under GraphicsMagick there are two script files called CopyLibsFromDropbox.cmd and CopyLibsToDropbox.cmd, the first of which contains
echo You can download the library files here: https://www.dropbox.com/sh/a8krszzmo76fqkt/AAAc9Jho29Jk3iLrKhsBmw-Ma?dl=0
goto done
In that dropbox, you will find all the lib files you need. Download the whole thing as a .zip and extract the thing inside the the \GraphicsMagick directory. Should look like that now:
Once the libs are inside that folder you can actually compile the code. The scripts are for copying them from your local dropbox directory to this directory, if you choose to "save this inside my dropbox" at the dropbox download page above. In the end, you should see something like
3> GraphicsMagick.NET.Web -> C:\Users\Maxi\Downloads\graphicsmagick-d1b5b1b28f26cdedf3ceeb555b94a87609286740\GraphicsMagick.NET.Web\bin\ReleaseQ16\x86\GraphicsMagick.NET.Web-x86.dll
3> Codeanalysis is beeing executed...
3> Codeanalysis finished -- 0 Errors, 0 Warning(s)
========== Build: 2 successfull, 0 failed, 0 recent, 1 skipped ==========
(who cares why I need to build it?)
I do. You can already include managed dlls to Unity, and GraphicsMagick.NET already gives you a .NET dll which you should be able to use within Unity, or did you have any particular problems with that? Need some image processing functionality from that library?
We are using an environment variable to specify a path to a library we use. Most of the time it points to the released version but sometimes to a development version.
Anyway, it works ok when I use $(MyLib)/path;%(AdditionalIncludeDirectories) for building the C++ application but I can not open the project resources. However, when I use %(MyLib)/path;%(AdditionalIncludeDirectories) it works.
Now, what is the difference?
I thought the correct way is to use $(EnvVar) but for the resource editor it doesn't seems to work. And if $(EnvVar) is the correct way then why does Visual Studio use %(AdditionalIncludeDirectories) and not $(AdditionalIncludeDirectories)
The error I get is: fatal error RC1015: cannot open include file 'afxres.h'.
You use %(item) to refer to an MSBuild metadata item. Using $(AdditionalIncludeDirectories) would not work well if you also had an environment variable by that name. So %(MyLib)/path ought to resolve to just /path.
You can put echo %(MyLib)/path in a prebuild event to verify this.
Which is probably enough to stop confusing rc.exe, the resource compiler. Which is a stone-cold-old SDK utility, going back all the way to Windows version 1.0. It is pretty temperamental, very picky about command line options and .rc script file text encoding. Do keep in mind that it dates from an era long before Windows started to support a forward slash as a path separator, everybody had to use a backslash back in 1986.
So use "$(MyLib)\path" instead, including the double quotes so you don't confuzzle it when MyLib contains embedded spaces. And do favor using a project property sheet instead so there are some odds that somebody can still figure out how to get the project built correctly 2+ years from now.
I'm trying to set my project include to the path %OPENCV_246%\..\..\include
This resolves to the path F:\dev\opencv_246\build\include
However, when setting the project includes, that path will not resolve and as a result the included headers break.
I've tried both %OPENCV_246%\..\..\include and $(OPENCV_246)\..\..\include with no luck.
Using the path directly fixes my includes, but I'd like to have a better way of managing the path through environment variables.
In the screenshot I've added both for clarity, If anyone could point out the step I'm missing here I'd appreciate it.
EDIT: Variable OPENCV_246 contains value F:\dev\opencv_246\build\x86\vc11
Dev studio won't recognize any environment variables that have been changed since it was started, so if you change one, a restart is required (of Dev studio, not the computer).
https://superuser.com/questions/107521/why-are-changes-to-my-path-not-being-recognised
This sounded similar to my problem, which was getting VS2013 to acknowledge a change I made to my environment variable (in my case QTDIR). Even after a restart and a shutdown, it obstinately hung on to the old value !! (you can see the value if you go to edit a project setting, hit the "Macros" button, and scroll down the list to find e.g. "$(QTDIR)" )
Here it suggest VS2010 cahed values heavily, but 2013 seems even more keen !
After some FindInFiles for the old path, it seems that VS2013 caches environment variables in your .vcxproj.user file. I have no idea how it got in there in the first place.
So I deleted the entry, closed the solution, checked the file again in WordPad to make sure the entry hadn't been put back in. Then I re-opened the solution, but the old value was still there in the Macros list !
Closing VS seems to have done the trick. Now it seems to have the right path - although I'm sure I checked after I first opened the solution and QTDIR wasn't in the Macros list at all - maybe I'm confused...
Well, it all seems to be working now, and my project builds and links to my Qt libs without complaints :-)
And, the entry in the vcxproj.user file hasn't come back. So I still don't know how it got in there. Maybe I did something to cause it a while back in a previous version of VS...
I am using code::blocks.
I set up the MSVC compiler(downloaded the MSVC Express 2010 Compiler and then added SDK directories).
The project does compile, however when I try to debug it ingores the breakpoints I set.
If I go Settings->Compiler->Toolchain Executables, the chosen Compiler is GDB/CDB : Default.
I guess the problem is gdb cannot debug msvc code. But how do I add a ne debugger?
In Settings->Debugger there is only one option of GDB/CDB compiler and I cannot add new one.
I tried adding additional directories, but it doesn't help.
So how do I make it work?
thanks
It's in Settings/Debugger and not in in Settings/Compiler/Toolchain Executables.
Got the same problem... I set path for cdb in code::blocks, ensured that the compiler added debug info, did everything I found on google (set Symbol Path to some weird stuff as described here: http://forums.codeblocks.org/index.php/topic,8454.msg63355.html#msg63355 and here: http://msdn.microsoft.com/en-us/library/windows/hardware/hh439323%28v=vs.85%29.aspx) - and still nothing. I didnt have any errors in debuger log, but it still wouldn't work. Finally - EUREKA: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
Breakpoints could not work if the path/folder you've placed your
project contains spaces or other special characters. To be safe use
English letters, digits and '_'.
After changing " " to "_" in directory names - everything works fine. And I lost only 5 hours for that...
I had a VC2008 project very complicated.Inorder to understand it's inner workings I tried to simplify it and now I am getting 289 errors of the following type for most of the files:
Error 5 error C2471: cannot update program database 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb' c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
Error 6 fatal error C1083: Cannot open program database file: 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb': No such file or directory c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
My system : win7/VS2008
Solution 1: Locate *.vcxproj file in your solution, open in a text editor and search for 'DebugInformationFormat' and set it to 'OldStyle'. Reload your project and build. If you have multiple projects in your solution, this change needed for all the *.vcxproj files.
< DebugInformationFormat>OldStyle< /DebugInformationFormat>
Solution 2: From Visual Studio, on every project in your solution right click and open Properties. Expand 'Configuration Properties' > 'C/C++' > 'General'. Change the 'Debug Information Format' to 'C7 compatible (/Z7)'. Then build your solution.
This worked for me. (YMMV = Your mileage may vary:)
I've seen the same behaviour when converting a VS2003.Net solution to run on later IDEs. My guess is that your solution contains multiple projects which point to the same intermediate directory. In VS2005 and later, projects that don't depend on each other can be built in parallel so that if the same working dir is used, you can get file conflicts like this.
Check this as follows. In Solution Explorer, right click on one of the failing projects and select Properties. In Configuration Properties -> General section, make sure that every project has a different 'Intermediate Directory'. Try your build again using 'Rebuild Solution' to clean everything out.
Most of the times when I get "C2471: cannot update program database" it's because the PDB file is locked for some reason. Usually in my case that turns out to be because I have the program running in some other window, which loads the PDB file in to memory.
When that's not the reason, I find doing a rebuild-all magically fixes the problem.
I've encountered the same type of error myself with no end of frustration.
I finally fixed it by applying the Microsoft hot fix found in this knowledge base article: http://archive.msdn.microsoft.com/KB946040
This worked for me.
Kill mspdbsrv.exe and reload Visual C++
MSDN
You can delete the *.obj file and rebuild the solution again, This problem might solve. Below link might be helpful for you-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/vs2008-c2471-cannot-update-program-database?forum=vclanguage