I'm using PLC 1.11 installed from the allinone-msvc2019-win64.exe installer. I'm doing a command-line build using MS Build Tools and NMake. The code I'm testing the build with is the example from "Writing Point Cloud data to PCD files" tutorial. I can compile the resulting source to an object file just fine:
cl /c /Zi /EHsc /MTd /Fe.\intermediate\x86\pcd_write.obj /I"\Program Files\PCL 1.11.0\include\pcl-1.11" /I"\Program Files\PCL 1.11.0\3rdParty\Eigen\eigen3" /I"\Program Files\PCL 1.11.0\3rdParty\Boost\include\boost-1_73" .\src\pcd_write.cpp
But when linking, it tries to link to the wrong ABI tag for the boost library:
link /LIBPATH:"\Program Files\PCL 1.11.0\lib" /LIBPATH:"\Program Files\PCL 1.11.0\3rdParty\Boost\lib" /LIBPATH:"\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.26.28801\lib\x64" /out:.\bin\x86\pcd_write.exe .\intermediate\x86\pcd_write.obj
Microsoft (R) Incremental Linker Version 14.26.28806.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc142-mt-sgd-x64-1_73.lib'
Note that it should be libbost_filesystem-vc142-mt-gd-x64-1_73.lib. No "s". I'm assuming that I have a link argument wrong (or possibly a compiler argument wrong). But I can't weed through to figure out what. How do I tell the compiler/linker which Boost library to link to?
Related
After following tutorial from here. I can not generate executables using from lzma1900 SDK.
Here is the output from powershell.
PS C:\Users\testbench\Downloads\7ZipSDK\CPP> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat
PS C:\Users\testbench\Downloads\7ZipSDK\CPP> nmake NEW_COMPILER=1
MY_STATIC_LINK=1 Build.mak
Microsoft (R) Program Maintenance Utility Version 14.16.27030.1 Copyright (C) Microsoft Corporation. All rights reserved.
if not exist "o" mkdir "o"
if not exist "o/asm" mkdir "o/asm"
link -nologo -OPT:REF -OPT:ICF /LARGEADDRESSAWARE /FIXED:NO -out:o\
oleaut32.lib ole32.lib user32.lib advapi32.lib shell32.lib
LINK : fatal error LNK1104: cannot open file 'o\'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86\link.EXE"'
: return code '0x450'
Stop.
And I'm using this nmake version and ml.exe version:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx86\x86
I have also installed windows SDK. why it is not being loaded when I run that bat script.? and How can I compile the latest lzma SDK using visual studio 2017?
Posting answer for future reference, in case any one needs to look at it:
There are two source codes provided by 7-Zip's developer.
7-Zip application.
LZMA algorithm implementation in (C, C++ ,C#, java).
One can generate Executable for windows by using makefile located inside
7z1900-src/CPP/7zip/makefile.
I used MSBUILD commandpromt for 2015.(note: one more way to achieve this by running vcvarsall.bat and then executing "nmake" command
If you want to understand how 7Z works then "Alone.dsw " is what you're looking for. it is inside
7z1900-src/CPP/7zip/Bundles/Alone/Alone.dsw
You will need to change "Debug Information Format" to Program Database /Zi inside Project Property. it is under C/C++ -> General.
I hope it helps.
Turn off the Embed Manifest option in Project -> Properties -> Configuration Properties -> Manifest Tool -> Input and Output. Change the value of Embed Manifest to No. Find more
EDIT:
Having posted this to their issue tracker and stepped through it with some CMake devs, this actually isn't a CMake problem. Something is broken with my MSBuild installation that causes it to return the "The operation completed successfully." error. Still no resolution on the issue overall, but this narrows down the potential causes.
I'm trying to build a CMake project on Windows using the MS Visual C++ Build Tools 2015 (note: not full Visual Studio). CMake, however, is apparently unable to find cl.exe
cmake ..
-- Building for: Visual Studio 14 2015
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:4 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:4 (project):
No CMAKE_CXX_COMPILER could be found.
I suspect this is because CMake is expecting to find the compiler in with the Visual Studio installation but perhaps the standalone build tools install it in a different location? Is it possible to configure CMake to look elsewhere for the compiler?
EDIT: To head this possibility off at the pass, cl.exe is definitely installed. When I open the Visual C++ shell (adds the tools to the path) cl.exe outputs:
cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
And that is the same environment I'm running cmake .. from so cl.exe is definitely on the PATH for discovery by CMake.
EDIT 2: Looking at the CMakeError.log file I see a couple variants of the following
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 4/14/2017 11:58:13 AM.
Project "E:\<project_dir>\build\CMakeFiles\3.8.0-rc4\CompilerIdCXX\CompilerIdCXX.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdCXX.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdCXX.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /nologo /W0 /WX- /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TP /analyze- /errorReport:queue CMakeCXXCompilerId.cpp
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe" #C:\Users\<user>\AppData\Local\Temp\tmpa0925a9f05d5426d82afdcee8d722031.rsp". The operation completed successfully. [E:\<project_dir>\build\CMakeFiles\3.8.0-rc4\CompilerIdCXX\CompilerIdCXX.vcxproj]
Done Building Project "E:\<project_dir>\build\CMakeFiles\3.8.0-rc4\CompilerIdCXX\CompilerIdCXX.vcxproj" (default targets) -- FAILED.
Build FAILED.
"E:\<project_dir>\build\CMakeFiles\3.8.0-rc4\CompilerIdCXX\CompilerIdCXX.vcxproj" (default target) (1) ->
(ClCompile target) ->
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe" #C:\Users\<user>\AppData\Local\Temp\tmpa0925a9f05d5426d82afdcee8d722031.rsp". The operation completed successfully. [E:\<project_dir>\build\CMakeFiles\3.8.0-rc4\CompilerIdCXX\CompilerIdCXX.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.21
This looks like some kind of output compatibility issue, especially the "ERROR: The operation completed successfully." lines. I'm using CMake 3.8.0-rc4 and the Visual C++ 2015 Build Tools. Any ideas?
EDIT 3:
I thought that upgrading from 3.8.0-rc4 to 3.8.0 might fix it, but no avail. I also considered that I was using 64bit CMake trying to build a 32 bit program so I changed that as well. No luck yet.
EDIT 4:
Also, for the record, this does build with CMake on a PC with full VS 2015 installed.
I'm not sure I bring a solution to your The operation completed successfully problem, but I was able to compile a [big] real-life project using cmake 3.8.1 and C++2015 BuildTools.
The trick is simply to use the "VS2015 x64 Native Tools Command Prompt" (or x86). You either call cmake using this prompt, or you call this prompt from your normal prompt and it will set your path properly.
REM Set up the include/lib paths of Visual Studio
call "C:\Program Files (x86)\Microsoft Visual C++ Build Tools\vcbuildtools.bat" amd64
cd to_build_dir
REM Call cmake with the right parameters
"C:\Program Files\CMake\bin\cmake.exe" .......
REM Build the XYZ project
MSBuild.exe SOLUTION_FILE.sln /t:XYZ .......
As I wrote, I'm not sure it will fix your error because I wasn't able to reproduce it. However, I know that my project compile only when I use the right prompt. When I'm not using it, I get some error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
What I want to be done: Create a 64bit DLL on win7 that interacts with the Windows API including the OLE32.dll.
What I have got:
I am currently stuck. I download Visual Studio 2015 Community Edition. I tried to create a DLL there and on creation it generated everything but no dll. The program did not complain, everything was setup as in the tutorial but no dll file.
So I skipped this and downloaded Eclipse CDT. I set up using the Visual C toolchain and after minor issues I had my DLL generated. So I used Java to fire it up but it complained (I use JNA for integration) and it seams that I have a 32bit DLL.
So I searched the web and read and did stuff but I am totally lost. Since the Visual Studio 2010 Express edition came without a 64bit compiler I am not even sure if the Community edition of Visual Studio supports 64bit dlls this time.
I also have the Windows SDK v7.1 installed. I link to a library file ole32.dll. It contains the method CoCreateInstance which I require. I have to add this manually in order for the compiler to pick it up. If I switch to the 64bit dll version the compiler complains about the CoCreateInstance method can not be linked.
So basically I am lost here. A source on the web gave a work around for the 2010 Express being not able to create x64 DLL and it turned out that the hint was getting windows SDK since it it comes along with a compiler.
Also I noticed that CDT uses Visual Studio 10 files so I guess it is using this compiler.
I set to both compiler and linker the /machine:64 option. But the linker still complains that the obj file from the compiler is 32bit.
Any Ideas?
[Update]
The Compiler prints the following line so basically it is not able to compile 64bit version. Any idea how to replace it? As said it uses the Visual Studio 10 folder but I also have a Visual Studio 12 and 14 folder as well.
cl : Command line warning D9002 : ignoring unknown option '/machine:x64'
Well, I don't think '/machine:x64' is a cl option but it's one of linker option.
If you want to make some dll maybe with windows sdk or visual studio environment.
I am not sure that my solution is fit for yours or not, this is what i did for my 64-bit project to compile with eclipse and windows sdk 7.1.
I have two eclipse IDEs which are 32bit and 64bit neon version.
I choose a 64-bit one. You can check one of my answer about installation here. In my opinion, any version of them will be fine. It is your choice.
First step. run 'Windows SDK 7.1 Command Prompt from the start menu.
then, start my eclipse on the command window after changing 64-bit development level with command as follows.
Second Step. Setting up path variables to my project.
I have my own project with a properties window.
The important variable seems to be both LIB and PATH variable in my point.
I crosschecked this two variable, one was from the windows SDK's prompt window and another was current setting variables after installation.
SDK variables here
My final variables are
LIB:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\X64
PATH:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\VCPackages;;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin;;
C:\Windows\system32;C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
Third, I modified my linker flag as you see the picture below.
Finally, I compiled my project successfully.
Here is my build log.
Info: Internal Builder is used for build
cl /c /EHs /MD /Zi /nologo /Foutil.obj "..\util.c"
rc /Fo proc_view.res "..\proc_view.rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /EHs /MD /Zi /nologo /Foprocss.obj "..\procss.c"
link /machine:x64 /debug /nologo /OUT:Systemer.exe FreeList.obj LinkedList.obj proc_main.obj proc_view.res procss.obj util.obj Kernel32.lib Psapi.lib User32.lib
The last one had done with checking if my executable file was 64-bit or 32-bit with a dumpbin command.
That is all.
I think the Eclipse with MinGW or cygwin might be a better option.
I hope this is right for you.
I have installed SDK 7.1 and am attempting a port of a C/C++ project from MinGW (32-bits) to the VC 2010 that comes with SDK 7.1 at 64 bits. I am compiling in the command line environment set up for the SDK when it was installed.
I got all the files to compile, but linking defeated me, both when I set up a build with static linking of the C/C++ run-time, and when I set up an alternate build with dynamic linking of the C/C++ run-time.
For example Kernel32.lib is a part of my linkage, and it's here, C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\Kernel32.Lib that I confirmed it's being retrieved from, and yet the following linkage error is one of the many reported by both builds.
error LNK2019: unresolved external symbol __imp__CloseHandle#4
How can these linkage problems be resolved? There is no other x64 Kernel32.lib in the SDK or with the VC 2010 that came along with it.
If you are in the correct command line environment, which can be set up by calling %VS100COMNTOOLS%\..\..\VC\vcvarsall.bat x64 from a command prompt if VS 2010 is installed, then the following simple program can be compiled with just cl test.cpp. kernel32.lib is linked in automatically since all Windows applications require it:
#include <windows.h>
int main()
{
HANDLE h;
CloseHandle(h);
}
It sounds like you are using the 32-bit compiler and specifying the 64-bit kernel32.lib explicitly, which I can reproduce. Note the banner "32-bit C/C++ Optimizing Compiler...":
C:\>cl test.cpp -link "c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\Kernel32.Lib"
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
c:\test.cpp(6) : warning C4700: uninitialized local variable 'h' used
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test.exe
"c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64\Kernel32.Lib"
test.obj
test.obj : error LNK2019: unresolved external symbol __imp__CloseHandle#4 referenced in function _main
I'm having trouble with the VC++ compiler. I've installed the windows sdk with compilers, libraries and headers, and tried to compile a test program like so:
#include <cstdio>
int main(int argc, char* argv[]) {
printf("%s", "Hello world!");
return 0;
}
This is the command line script i'm using to compile:
#echo off
set clpath=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
set clname=cl.exe
set linkpath=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64
set linkname=link.exe
set libpath=/libpath:"C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib" /libpath:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib"
set includepath=/I "C:\Program Files\Microsoft SDKs\Windows\v7.1\Include" /I "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include"
set subsystem=console
set entry=main
set libfiles=
set cfiles=hello.cpp
set objfiles=hello.obj
set path=%clpath%
%clname% %includepath% /c %cfiles%
set path=%linkpath%
%linkname% %libpath% /subsystem:%subsystem% /entry:%entry% %libfiles% %objfiles%
And here's the output:
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64
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.
hello.obj : error LNK2019: unresolved external symbol printf referenced in function main
hello.exe : fatal error LNK1120: 1 unresolved externals
The program links fine as long as i'm not trying to reference any standard library functions. I've tried messing around with the NODEFAULTLIB and DEFAULTLIB switches as well as specifying the standard libs to link to directly, to no avail.
Your library paths are wrong. This folder:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib
contains the x86 libraries. You're targeting amd64, so you need the amd64 libraries, from:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\lib\amd64
(You'll also need the correct amd64 library path for the Windows SDK; I don't have v7.1 installed, so I don't know exactly what that is.)
Note that you can configure your environment with all of the correct paths and environment variables simply by running:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64
On a related note, setting /entry:main is wrong: the entry point needs to be the CRT initialization entry point. If you define a main function, then this is mainCRTStartup. The linker will pick this function as the entry point by default, so you do not need to specify an entry point using /entry.
Try adding libcmt.lib to libfiles=
Click here for more info on linking against C-libs on Windows.
BTW. The major advantage of running VC++ is a good IDE. Why do you need to build it from command-line?