i just downloaded boost 1_45_0 for windows. i have vc++6 installed on my windows 7 64bit pc. in the windows introduction, i'm told to try to compile a small lambda program.
i placed boost in the root of c:, i have c:\boost\boost_1_45_0. i added "c:\boost\boost_1_45_0" to my "include" environment variable in the windows advanced system settings
what else do i need to do before i c
when i try to compile at the command prompt, i get the following:
C:\test\boost>cl /EHsc /I c:\boost\boost_1_45_0 boost.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
boost.cpp
c:\boost\boost_1_45_0\boost/config/suffix.hpp(596) : error C2039: 'typeinfo' : i
s not a member of '`global namespace''
c:\boost\boost_1_45_0\boost/config/suffix.hpp(596) : error C2873: 'typeinfo' : s
ymbol cannot be used in a using-declaration
c:\boost\boost_1_45_0\boost/mpl/aux_/yes_no.hpp(56) : fatal error C1506: unrecov
erable block scoping error
You are using a compiler that is now 12 years old, and boost doesn't support it. You'll need VS.Net 2003 at a minimum, but I'd strongly recommend VS2008 or VS2010. There is a free 'express' version of VS2010. Unless you have a very specific need to use VC++6 I would ditch it now.
Related
Having an unusual problem running Win32C++ source codes with the function DCompositionCreateDevice2, which is compiled with VS 2015.
The source codes compile without any error but display the above runtime error. Recompiling and running the same source codes with VS 2019, there is no runtime error.
The test sample codes are Windows SDK samples listed below:
TouchInputDirectManipulation
DCompV2BackfaceandD2DBatching
Any idea what could be the source of this problem? I am working on WTL open source project, and do not want to restrict the build environment to VS 2019.
This is actually an unusual issue... What happens is Microsoft has seriously messed up dcomp.lib between the Windows 8.1 SDK and the Windows 10 SDK.
Here is what you see if you dump the Windows 8.1 SDK dcomp.lib exports:
C:\>dumpbin "C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64\dcomp.lib" /exports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Exports
ordinal name
DCompositionCreateDevice
1017 DCompositionCreateDevice2
DCompositionCreateSurfaceHandle
And here is what you see if you dump the Windows 10 SDK dcomp.lib exports:
C:\>dumpbin "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64\dcomp.lib" /exports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Exports
ordinal name
DCompositionAttachMouseDragToHwnd
DCompositionAttachMouseWheelToHwnd
DCompositionCreateDevice
DCompositionCreateDevice2
DCompositionCreateDevice3
DCompositionCreateSurfaceHandle
As you can see the DCompositionCreateDevice2 was defined with ordinal 1017 initially. When you build your program using the Windows 8.1 SDK (which is how theses samples are currently defined), you get that using dumpbin:
C:\>dumpbin c:\mypath\TouchInputDirectManipulation\cpp\x64\Debug\DirectManipulationSample.exe /imports
Microsoft (R) COFF/PE Dumper Version 14.28.29914.0
Copyright (C) Microsoft Corporation. All rights reserved.
Section contains the following imports:
dcomp.dll
140054570 Import Address Table
140054E98 Import Name Table
0 time date stamp
0 Index of first forwarder reference
Ordinal 1017
So, your .exe is linked to ordinal 1017, not to exported name DCompositionCreateDevice2.
The problem is, with Windows 10 (I think you're running on Windows 10), dcomp ordinal 1017 is not DCompositionCreateDevice2 but DCompositionAttachMouseDragToHwnd! This can be confirmed if you debug your program, you land into that function that doesn't like what you send to it and reports E_INVALIDARG.
So the solution is to change the SDK if you target Windows 10:
Or simply use GetProcAddress("DCompositionCreateDevice2") etc. to dcomp.dll to make sure you get the good one.
This should be reported to Microsoft I guess...
I am trying to build the source of CURA; (Link: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Windows). I followed the instructions but got error as below:
PS D:\work\cura-build-environment-master\build> nmake
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.
It looks like you may not have followed all of the instructions, such as this one in the Microsoft Visual Studio 2019 section:
When building files (using cmake or nmake) in the steps below be sure to use the 'VS2015 x64 Native Tools Command Prompt'. This ensures that the Visual Studio 2015 build tools are used.
I am trying to run vcbuild in XP 64 bit and visual studio 2008. The problem is rather puzzling, both because it makes little sense, and because I know very little of windows.
I am actually going to run it from cygwin, but it's not relevant I think. The error message in the title is the one I get on cygwin, and it spawned further research.
I am running windows 64 bit, installed VS2008 (with x64) and updated all the bunch.
When I open a terminal, and I try to invoke vcbuild, I get this
C:\Documents and Settings\Administrator\Desktop>"C:\Program Files (x86)\Microsof
t Visual Studio 9.0\VC\bin\amd64\vcbuild.exe"
The system cannot execute the specified program.
There's another vcbuild that runs
C:\Documents and Settings\Administrator\Desktop>"C:\Program Files (x86)\Microsof
t Visual Studio 9.0\VC\vcpackages\vcbuild.exe"
Microsoft (R) Visual C++ Project Builder - Command Line Version 9.00.21022
Copyright (C) Microsoft Corporation. All rights reserved.
but as far as I understand it's 32 bit. I tried running dependency walker, and indeed it turns out that the first one is a 64 bit program (note the 64 bit icon), linking to 32 bit libs (???)
and the second one is a 32 bit program linking against 32 bit libs
I have no idea of what went wrong (or is wrong). I would say it is a variable definition problem. I tried calling vcvarsall.bat x64
C:\Documents and Settings\Administrator>"c:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\vcvarsall.bat" x64
Setting environment for using Microsoft Visual Studio 2008 Beta2 x64 tools.
but no luck. Any idea ?
I just installed Windows SDK 7.1 on Windows XP Professional with SP3. Now I'm checking to see if the installation is OK and, already, I'm having a problem. I still cannot get cl.exe compile a simple hello world C++ code from the Windows SDK 7.1 Command Prompt. Here is a snapshot of command prompt output:
Setting SDK environment relative to C:\Program Files\Microsoft SDKs\Windows\v7.1\.
Targeting Windows XP x86 Debug
C:\Program Files\Microsoft SDKs\Windows\v7.1>cd /d "D:\My Documents\Sources"
D:\My Documents\Sources>cl /EHsc /FeD:\Target\hello hello.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.cpp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file 'C:\Documents'
I tried moving hello.cpp to D:\ and ended up with the same result. CSC.exe, on the other hand, compiled a hello world C# code in the same command prompt without a hitch. What should I do now?
Note that I do not have any version of Visual Studio installed. I installed Windows SDK so that I can use Qt Framework 4.8.0 for VS2010 in Qt Creator and learn a little bit of C# in SharpDevelop.
Some people adviced me to wrap all environment variable values containing C:\Documents and Settings\ in double quotes, e.g.: Set ALLUSERSPROFILE="C:\Documents and Settings\All Users", Set USERPROFILE="C:\Documents and Settings\Ant Luc", and so forth. There was no sane way to perform the modification, except for %TEMP% and %TMP%, since they were not available for editing through System Properties > Advanced > Environment Variables. So I edited C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd and added the following lines right below #ECHO OFF:
SET ALLUSERSPROFILE="C:\Documents and Settings\All Users"
SET USERPROFILE="C:\Documents and Settings\Ant Luc"
SET HOMEPATH="C:\Documents and Settings\Ant Luc"
SET APPDATA="%USERPROFILE%\Application Data"
SET TEMP="%USERPROFILE%\Local Settings\Temp"
SET TMP="%USERPROFILE%\Local Settings\Temp"
But I then got Error C1083 when compiling the hello world code with cl.exe. In desperation, I edited C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd again, and changed the value for %TMP% to D:\VSTEMP, created a directory called VSTEMP in D:\, tried to compile the source code again, and sighed in relief because it finally compiled successfully.
I decided to grab and install Visual Studio 2010 Express out of curiosity, opened Visual Studio Command Prompt, tried to compile the same hello world code, and was faced with the same set of problems which I fixed with the same workaround. Conclusion: the compiler (or linker) cannot properly handle whitespace in %TMP% -- assign a directory without a single whitespace to it.
I still do not know what is wrong with my setup, but all this hassle seems stupid anyway. FWIW, this is the first toolchain that made me jump through hoops just to get a hello world code compile successfully.
We have an automated build system, which builds a variety of Visual Studio 2005 solution files. These solutions contain various Visual C++ and Intel Fortran projects.
We are in the process of upgrading our Intel Fortran compiler, and Visual Studio is currently setup to be integrated with the old Intel compiler (ver 9.1).
I'm looking for a way to tell Visual Studio to use the new Intel Fortran compiler (ver 11). I need to be able to tell Studio to do this just for our compiler upgrade project, with it's default remaining as is (using ver 9.1) so that our standard builds can continue without being affected by the upgrade project.
Does anybody know if this is possible? I.e., can I tell Visual Studio which Intel compiler to use via the command line?
At the moment, I can use the batch scripts that Intel supply to setup the LIB=, INCLUDE= and PATH= environment variables. However, when Visual Studio compiles the Fortran projects, it's using ver 9.1.
What about the "/useenv" command line to devenv.exe?
C:\>devenv /?
Microsoft (R) Visual Studio Version 8.0.50727.867.
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Use:
devenv [solutionfile | projectfile | anyfile.ext] [switches]
...
/useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables
instead of IDE paths for VC++ builds.