Am trying to compile a 64bit version of PyISAPIe using VS2010. Am not used to C/C++ programming but managed to configure some settings for VS2010. Everything went well until it got to the linking stage where it gave the above mentioned error. I checked all the Library path settings and they looked fine. Below is my command line for building the DLL:
/OUT:"x64\Release\PyISAPIe.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\pyisapie\Python\x64\Python27\libs" /LIBPATH:"C:\pyisapie\Python\x64\Python26\libs" /LIBPATH:"C:\pyisapie\Python\x64\Python25\libs" /DLL "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /NODEFAULTLIB:"libc libcmt msvcrt" /DEF:"PyISAPIe.def" /MANIFEST /ManifestFile:"x64\Release\PyISAPIe.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"C:\pyisapie\x64\Release\PyISAPIe.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /PGD:"C:\pyisapie\x64\Release\PyISAPIe.pgd" /LTCG /TLBID:1 /DYNAMICBASE:NO /IMPLIB:"x64\Release\PyISAPIe.lib" /MACHINE:X64 /ERRORREPORT:QUEUE
The path C:\pyisapie\Python\x64\Python27\libs exists and containes python27.lib.
Can anyone help me out. Thanks in advance
I just compared your linker command line to mine (I'm the project author) and it's exactly the same as far as flags go, so you might want to look into other reasons why the file can't be opened. Is it an x64 lib for sure? Do you have access?
You might try reinstalling the newest 2.7 x64 release into a different location and add that folder instead.
I had the same issue due to not setting the LIBPATH correctly. This may not be the cause of your error message, but it was the cause of mine.
To resolve it in Visual Studio right click on the PyISAPIe project and select:
Properties > Configuration Properties > Linker > General
Then make sure that the path C:\pyisapie\Python\x64\Python27\libs (or the relative path) is listed in the "Additional Library Directories"
Related
I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3
Visual Studio 2017 comes with full CMake integration. To learn about this combination, I was starting with this basic sample:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(foo)
add_executable(foo foo.cpp)
and
// foo.cpp
int main() {}
This properly generates build scripts, and compiles and links with no issues. That was easy.
Trying to set compiler options, on the other hand, turned out to be anything but trivial. In my case I was attempting to set the warning level to 4.
The obvious solution
add_compile_options("/W4")
didn't pan out as expected. The command line passed to the compiler now contains both /W4 (as intended) as well as /W3 (picked up from somewhere else), producing the following warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
To work around this, I would need to replace any incompatible compiler option(s) instead of just adding one. CMake does not provide any immediate support for this, and the standard solution (as this Q&A suggests) seems to be:
if(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
This, however, has two issues:
It sets the global CMAKE_CXX_FLAGS, applying to all C++ targets. This may not be intended (not an issue for me right now).
It doesn't scale. For every compiler option to add, you would have to read up on incompatible options, and manually strip those first. This will inevitably fail1.
My question is two-fold:
Where does the CMake integration pick up default settings from, and can this be controlled?
How do you set compiler options in general? (If this is too broad a topic, I'd be happy for help on setting the warning level only.)
1 Incidentally, the solution I replicated fails to account for the /Wall option, that is incompatible with /W4 as well.
The default settings for the compiler are picked up from standard module files located in the Modules directory of the CMake installation. The actual module file used depends on both the platform and the compiler. E.g., for Visual Studio 2017, CMake will load the default settings from the file Windows-MSVC.cmake and language specific settings from Windows-MSVC-C.cmake or Windows-MSVC-CXX.cmake.
To inspect the default settings, create a file CompilerOptions.cmake in the project directory with the following contents:
# log all *_INIT variables
get_cmake_property(_varNames VARIABLES)
list (REMOVE_DUPLICATES _varNames)
list (SORT _varNames)
foreach (_varName ${_varNames})
if (_varName MATCHES "_INIT$")
message(STATUS "${_varName}=${${_varName}}")
endif()
endforeach()
Then initialize the CMAKE_USER_MAKE_RULES_OVERRIDE variable in your CMakeLists.txt:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
set (CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake")
project(foo)
add_executable(foo foo.cpp)
When the project is configured upon opening the directory using Open Folder in Visual Studio 2017, the following information will be shown in the IDE's output window:
...
-- CMAKE_CXX_FLAGS_DEBUG_INIT= /MDd /Zi /Ob0 /Od /RTC1
-- CMAKE_CXX_FLAGS_INIT= /DWIN32 /D_WINDOWS /W3 /GR /EHsc
-- CMAKE_CXX_FLAGS_MINSIZEREL_INIT= /MD /O1 /Ob1 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE_INIT= /MD /O2 /Ob2 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT= /MD /Zi /O2 /Ob1 /DNDEBUG
...
So the warning setting /W3 is picked up from the CMake variable CMAKE_CXX_FLAGS_INIT which then applies to all CMake targets generated in the project.
To control the warning level on the CMake project or target level, one can alter the CMAKE_CXX_FLAGS_INIT variable in the CompilerOptions.cmake by adding the following lines to the file:
if (MSVC)
# remove default warning level from CMAKE_CXX_FLAGS_INIT
string (REGEX REPLACE "/W[0-4]" "" CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT}")
endif()
The warning flags can then be controlled by setting the target compile options in CMakeLists.txt:
...
add_executable(foo foo.cpp)
target_compile_options(foo PRIVATE "/W4")
For most CMake projects it makes sense to control the default compiler options in a rules override file instead of manually tweaking variables like CMAKE_CXX_FLAGS.
When making changes to the CompilerOptions.cmake file, it is necessary to recreate the build folder. When using Visual Studio 2017 in Open Folder mode, choose the command Cache ... -> Delete Cache Folders from the CMake menu and then Cache ... -> Generate from the CMake menu to recreate the build folder.
Turning my comment into an answer
CMake does come with some compiler switches preset. For visual studio those are mainly standard link libraries, warning levels, optimization levels, exception handling, debug information and platform specific defines.
What you now have to differentiate when you want to change a CMake generated compiler settings are the following use cases:
Additional compiler flags CMake does not define vs. changing CMake's preset settings
Project default settings vs. project user defined settings
So let's discuss common solutions for those cases.
User changes/adds to Project/CMake Compiler Flags Defaults
The standard way would be to modify the cached compiler flags variables by using tools shipped with CMake like cmake-gui and ccmake.
To achieve this in Visual Studio you would have to:
CMake / Cache / View CMakeCache
Manually change e.g. CMAKE_CXX_FLAGS to /Wall
CMakeCache.txt
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /Wall /GR /EHsc
CMake / Cache / Generate
Or you preset the CMAKE_CXX_FLAGS cache variable via a CMakeSettings.json file:
CMake / Change CMake Settings
Force the cache entry with -DCMAKE_CXX_FLAGS:STRING=... in cmakeCommandArgs
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_CXX_FLAGS:STRING=\"/DWIN32 /D_WINDOWS /Wall /GR /EHsc\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
If you deliver this CMakeSettings.json file with your CMake project it gets permanent
Project changes to CMake Compiler Flags Defaults
If you want to keep most of CMake's compiler flags in place, #sakra's answer is definitely the way to go.
For my VS projects I've put the CXX flag settings into a toolchain file coming with the project itself. Mainly to freeze those settings and don't have a dependency the CMake version used or any environment variables set.
Taking the example from above that would look like:
VS2017Toolchain.cmake
set(CMAKE_CXX_FLAGS "/DWIN32 /D_WINDOWS /Wall /GR /EHsc" CACHE INTERNAL "")
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE:FILEPATH=\"${projectDir}\\VS2017Toolchain.cmake\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
References
Visual C++ Team Blog: CMake support in Visual Studio – the Visual Studio 2017 RC update
set diagnostics:caret from CMakeLists.txt
Is Cmake set variable recursive?
Passing compiler options cmake
In CMake 3.15, CMake introduced a fix for this MSVC-specific warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
and the compiler warning flags (like /W3) are no longer automatically added. So by upgrading to CMake 3.15 or greater, this warning should no longer appear. From the docs:
When using MSVC-like compilers in CMake 3.14 and below, warning flags like /W3 are added to CMAKE_<LANG>_FLAGS by default. This is problematic for projects that want to choose a different warning level programmatically. In particular, it requires string editing of the CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin defaults so they can be replaced.
CMake 3.15 and above prefer to leave out warning flags from the value of CMAKE_<LANG>_FLAGS by default.
Along with this fix, CMake introduced policy CMP0092, which allows you to switch back to the OLD behavior (adding the warning flags by default) if necessary.
I downloaded a source code from codeproject.com
In the zip file only .cpp files and .hpp files were present but no .dsw (vc++ work space) file.
how to compile the files in vc++.
source code link: http://www.codeproject.com/Articles/13852/BasicExcel-A-Class-to-Read-and-Write-to-Microsoft
As far as I know, vc++ requires a dsw. That said, you can easily create one by creating a project + workspace and add import all the files into the project.
Unless the code requires special compile options (unlikely if it comes without a project file), this should work fine.
When you compile in VisualC++ cl.exe is executed in order to compile a s program.
So a way to compile that does not require dsw file might be running compilation in command line. This is an example for a source file main.cpp:
call vsvars32.bat && cl /MD /Od /EHsc /GR /Zi /Oy- main.cpp
On my computer the full path to vsvars32.bat is
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat
dsw is an ancient format, and is replaced by .sln and .vcxproj files. What I would suggest would be File -> New -> Project from existing code, browse to the directory with the cpp/hpp files and let Visual Studio create the project with default compiler switches - so you won't have to run cl.exe from the command line as suggested here.
That being said, the chances of circa-2006 c++ code to work on IDEs 4 versions later are small. You will almost certainly have to understand and fix the code - or find a more recent one that does what you need.
I just downloaded OpenNI 2 SDK (www.openni.org) and I am trying to setup a project in Visual Studio 2012.
What I did:
Create a new C++ Win32 Console Application Project
Go to Project>MyProject Properties and, in Configuration Properties>VC++ Directories...
Added C:\Program Files (x86)\OpenNI2\Redist\; to Executable Directories
Added C:\Program Files (x86)\OpenNI2\Include\; to Include Directories
Added C:\Program Files (x86)\OpenNI2\Redist\; to Reference Directories
Added C:\Program Files (x86)\OpenNI2\Lib\; to Library Directories
But when I try to build I have the following unresolved symbol error (where ConsoleApplication1 is my project's name)
Error 1 error LNK2019: unresolved external symbol
__imp__oniInitialize referenced in function
"public: static enum openni::Status __cdecl openni::OpenNI::initialize(void)"
(?initialize#OpenNI#openni##SA?AW4Status#2#XZ)
c:\Users\MyPC\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.obj
ConsoleApplication1
I know this linking error is saying that the linker can't find some libraries but I thought what I just did was enough.
I also tried the 64 bit version, creating a 64 bit project, but I have the same errors.
I couldn't find satisfying documentation on this topic.
I'm sure I'm missing something silly. Can you please give some advice on this?
Also you should do the below steps:
0-In the C/C++ section, under the "General" node, select
"Additional Include Directories"
and add
"$(OPENNI2_INCLUDE)" (if you use the 32-bit version) or
"$(OPENNI2_INCLUDE64)" (if you use the 64-bit version).
These are environment variables that point to the location of the OpenNI Include directory. (The defaults are :
C:\Program Files\OpenNI2\Include or
C:\Program Files (x86)\OpenNI2\Include)
1-In the Linker section, under the "General" node, select
"Additional Library Directories"
and add
"$(OPENNI2_LIB)" (if you use the 32-bit version) or
"$(OPENNI2_LIB64)" (if you use the 64-bit version).
These are environment variables that point to the location of the OpenNI Lib directory. (The defaults are:
C:\Program Files\OpenNI2\Lib or
C:\Program Files (x86)\OpenNI2\Lib)
2-In the Linker section, under the input node, select
"Additional Dependencies"
and add
OpenNI2.lib or OpenNI2.lib
3-Ensure that you add the Additional Include and Library directories to both your Release and Debug configurations.
4-Copy all the files from OpenNI's redist directory (see environment variable "$(OPENNI2_REDIST)" or "$(OPENNI2_REDIST64)") to your working directory. (The defaults are
C:\Program Files\OpenNI2\Redist or
C:\Program Files (x86)\OpenNI2\Redist).
Be aware that when you run from command line, the working directory is the directory where the executable can be found, and where you run from Visual Studio the default directory is where the project file (.vcproj, .vcxproj) can be found.
you also need to point to the actual library file: openni2.lib
If you add all of options (Include, Lib, ...) to your project setting and again get this error, maybe your project platform is Win32 and you want to use OpenNI x64
In this case, you must change the platform to x64 (Project properties at the top of the page)
If you don't have x64 option, make a new one ;)
I am trying to build the boost.thread library for Visual Studio 9.0. I used bjam to build the lib-files:
bjam toolset=msvc-9.0 variant=release threading=multi link=shared
The compilation succeeded and I got plenty of .lib and .dll files under boost/stage/lib.
Then I added include path and the above lib path to Visual Studio 9.0.
But when I try to compile some program, I always get the following error:
libboost_thread-vc90-mt-s-1_49.lib cannot be opened.
The lib file created by the build has slightly another name:
boost_thread-vc90-mt-1_49.lib
I tried to rename my file to match the expected name, but Visual Studio still cannot find the file.
It seems that the filename beeing seaarched depends on the project option "C/C++ / Code generation / runtime library". I need the option "Multithreaded /MT".
What am I doing wrong?
Thank you in advance.
You're trying to link statically with CRT, but dynamically - with Boost. This is not a good idea, but if you insist, you should define BOOST_ALL_DYN_LINK macro.
Better option would be to select /MD in your project options, or to set "link=static" when building boost.