I have set up static library builds of zlib and libpng. Both compile fine into .lib files. I am using MSVC 2010.
With this setup, to use libpng.lib, you need to link against zlib.lib as well. To avoid this, I'm trying to use lib.exe to link zlib into libpng directly. My invocation looks like:
call "C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/lib.exe" /OUT:x64\Release\libpng2.lib x64\Release\libpng.lib ..\zlib\x64\Release\zlib.lib /LTCG
In both of their project settings, I explicitly set "Librarian->General->Target Machine" to MachineX64. And, using dumpbin, I can check that the relevant zlib.lib and libpng are both compiled for x64.
Additionally, "General->Whole Program Optimization" and "C/C++->Optimization->Whole Program Optimization" have identical values.
The problem only occurs for x64 Release configurations. x86 Debug, x86 Release, and x64 Debug all work fine.
EDIT: Specifically, the problem is that I get a C1905/LNK1257 error:
C1905: Front end and back end not compatible (must target same processor).
LNK1257: code generation failed
I ran into this problem with VS2012. The lib.exe you're calling is part of the x86 tools. In the amd64 subfolder in VC/bin you will find the x64 versions. Opening a Visual Studio x64 Win64 Command Prompt will set your PATH correctly or you can call the x64 lib.exe directly, specifying its full path as you are doing now.
Related
I am trying to build a c++/cuda extension with Pytorch following the tutorial here, (with instructions how to use pytorch with c++ here). My environment details are:
Using Microsoft Visual Studio 2019 version 16.6.5
Windows 10
libtorch c++ debug 1.70 with cuda 11.0 installed from the pytorch website
I am using this cmake code where I set the include directory for python 3.6 and the library for python36.lib
cmake_minimum_required (VERSION 3.8)
project ("DAConvolution")
find_package(Torch REQUIRED)
# Add source to this project's executable.
add_executable (DAConvolution "DAConvolution.cpp" "DAConvolution.h")
include_directories("C:/Users/James/Anaconda3/envs/masters/include")
target_link_libraries(DAConvolution "${TORCH_LIBRARIES}" "C:/Users/James/Anaconda3/envs/masters/libs/python36.lib")
if (MSVC)
file(GLOB TORCH_DLLS "${TORCH_INSTALL_PREFIX}/lib/*.dll")
add_custom_command(TARGET DAConvolution
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${TORCH_DLLS}
$<TARGET_FILE_DIR:DAConvolution>)
endif (MSVC)
I set the CMake command arguments to be -DCMAKE_PREFIX_PATH=C:\libtorch (my path to libtorch debug mentioned above). I am building with the x64-debug option in MSVC version (as building with the x-64 Release option gives me a torch-NOTFOUND error).
The example DAConvolution.cpp file is:
#ifdef _DEBUG
#undef _DEBUG
#include <python.h>
#define _DEBUG
#else
#include <python.h>
#endif
#include <torch/extension.h>
Where I have undefined the _DEBUG flag so that the linker does not look for the python36_d.lib file (which I do not have).
I am getting a linking error:
Simply including torch.h works fine, but when I want to include the extension header thats when I get these problems, as it uses Pybind 11 I believe. Any insights much appreciated. I have tried to include all the info I can, but would be happy to give more information.
For Windows and with Visual studio, you are better to work with the Visual Studio rather than the CMake.
Just create a simple Console Application, go to the project's Properties, change the Configuration type to Dynamic Library (dll), Configure the include and Library directories, add the required enteries to your linker in Linker>Input (such as torch.lib, torch_cpu.lib, etc) and you are good to go click build, and if you have done everything correctly you'll get yourself a dll that you can use (e.g loading it using torch.classes.load_library from Python and use it.
The Python debug version is not shipped with Anaconda/ normal python distribution, but if you install the Microsoft Python distribution which I believe can be downloaded/installed from Visual Studio installer, its available.
Also starting from Python 3.8 I guess the debug binaries are also shipped.
In case they are not, see this.
For the cmake part you can follow something like the following. This is a butchered version taken from my own cmake that I made for my python extension some time ago.
Read it and change it based on your own requirements it should be straight forward :
# NOTE:
# TORCH_LIB_DIRS needs to be set. When calling cmake you can specify them like this:
# cmake -DCMAKE_PREFIX_PATH="somewhere/libtorch/share/cmake" -DTORCH_LIB_DIRS="/somewhere/lib" ..
cmake_minimum_required(VERSION 3.1 FATAL_ERROR)
project(DAConvolution)
find_package(Torch REQUIRED)
# we are using the C++17, if you are not change this or remove it altogether
set(CMAKE_CXX_STANDARD 17)
#define where your headers and libs are, specify for example where your DaConvolution.h resides!
include_directories( somewhere/Yourinclude_dir ${TORCH_INCLUDE_DIRS})
set(DAConvolution_SRC ./DAConvolution.cpp )
LINK_DIRECTORIES(${TORCH_LIB_DIRS})
add_library(
DAConvolution
SHARED
${DAConvolution_SRC}
)
# if you use some custom libs, you previously built, specify its location here
# target_link_directories(DAConvolution PRIVATE somewhere/your_previously_built_stuff/libs)
target_link_libraries(DAConvolution ${TORCH_LIB_DIRS}/libc10.so)
target_link_libraries(DAConvolution ${TORCH_LIB_DIRS}/libtorch_cpu.so)
install(TARGETS DAConvolution LIBRARY DESTINATION lib )
Side note:
I made the cmake for Linux only, so under Windows, I always use Visual Studio (2019 to be exact), in the same way I explained earlier. its by far the best /easiest approach imho. Suit yourself and choose either of them that best fits your problem.
I'm working on a basic makefile file to test compiling our sources for alternate Microsoft environments, like Windows Phone. I opened an VS2012 ARM Developer Command Prompt and ran nmake on the makefile. It resulted in:
nmake /f makefile.namke
...
cl /c cryptlib.cpp cpu.cpp...
cryptlib.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338):
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported.
cpu.cpp
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\crtdefs.h(338):
fatal error C1189: #error: Compiling Desktop applications for the ARM platform is not supported.
...
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\x86_ARM\cl.EXE"' : return code '0x2'
Stop.
"Desktop applications" is kind of ambiguous, so I searched Microsoft for the meaning of the term. It appears that means the toolchain is building x86 or x64 Metro UI-based application.
I feel like I'm suffering a disconnect, or Microsoft is suffering a disconnect and their tools are buggy.
Why is Microsoft's ARM version of cl.exe trying to build an x86 or x64 application instead of compiling for ARM? Or why is the VS2012 ARM Developer Command Prompt setting up for a x86 or x64 application?
I also tried remediating the problem, but the proposed solutions are not working. So now I am trying to understand what's going on at the highest levels.
For example, one answer says to add <WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport> to an ARM property sheet, but that did not work. Another answer says to add CXXFLAGS = /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, but that did not work either.
The makefile is about as simple as it gets to test the compile under Microsoft's ARM toolchain.
LIB_SRCS = cryptlib.cpp cpu.cpp ...
LIB_OBJS = cryptlib.obj cpu.obj ...
TEST_SRCS = test.cpp bench1.cpp bench2.cpp ...
TEST_OBJS = test.obj bench1.obj bench2.obj ...
CXX = cl.exe /nologo
AR = lib.exe
CXXFLAGS =
all: cryptest.exe
cryptest.exe: $(TEST_OBJS) cryplib.lib
$(CXX) $(CXXFLAGS) /ref:cryplib.lib /out:$# $(TEST_SRCS)
cryplib.lib : $(LIB_OBJS)
$(CXX) $(CXXFLAGS) $(LIB_SRCS)
$(AR) $(LIB_OBJS)
The correct solution would be to add something similar to /D WINAPI_FAMILY=WINAPI_FAMILY_APP or /D WINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP.
The Windows SDK headers have three different API subset targets, "desktop", "app" (the new "metro" style app introduced in windows 8) and "phone". When building from within Visual Studio, the right subset is chosen automatically depending on the project type, but when building manually by invoking cl.exe, you need to manually specify the target. (The chosen target limits what declarations are visible in the headers, hiding the ones that are unavailable in the more limited ones.)
Out of tradition, desktop is the default, but when targeting ARM, you need to choose one of the other ones, since there's no publicly supported target for third party code in desktop mode for ARM. (The WinRT tablets did have a desktop mode, but third parties weren't allowed to build apps for it.)
Since Windows 10 and MSVC 2015, you don't need to distinguish between phone and app, but should use "app" for both.
The other flag that was suggested, _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE, basically tells the headers to pretend like you are allowed to build for the desktop API family even for ARM. To use it, it seems like you should define it like this: /D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 (i.e. just defining it isn't enough, you should define it to 1). For plain code that doesn't use much of the windows API, this should also work equally well, but the better solution is to declare the real API target, to get proper warnings when trying to use APIs that aren't available.
Using Android NDK R10E, I am trying to build a shared library for all supported ABI's and I am getting the following error for some but not all ABI's:
[armeabi] SharedLibrary : libMyLib.so /home/user/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld:
fatal error: /home/user/source/MyLib/obj/local/armeabi/libMyLib.so: Input/output error
The project successfully builds for arm64-v8a, mips and mips64 but fails with the above error for armeabi, armeabi-v7a, x86 and x86_64.
I have a static library project and another shared library project and they both build successfully for all 7 ABI's.
If I compare the contents of obj/local/ for an ABI that builds and one that does not, they both contain all the same files except for libMyLib.so.
The difference between those two sets of ABIs is that the failing ones link using ld.gold and the working ones use ld.bfd.
Two things to try:
Use the 4.9 toolchain. It hopefully has the bug fix.
If that doesn't work, you can add -fuse-ld=bfd to your ldflags to use bfd even on the architectures that default to gold.
Same issue happened to me in r15c.
The fix was to copy
android-ndk-r15c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/arm-linux-androideabi/bin/ld.bfd over ld.
I had to copy it because I could not easily find a way to specify this flag to CMake to use it while detecting the compiler features.
My compile environment is windows xp and vc 6.0.
Now I have a c source file(msgRout.c), def file(msgRout.def), link file(msgRout.link), then I use commands below to get a 32 bit dll:
1.cl /I ../include -c -W3 -Gs- -Z7 -Od -nologo -LD -D_X86_=1 -DWIN32 -D_WIN32 -D_MT -D_DLL msgRout.c
2.lib -out:msgRout.lib -def:msgRout.def -machine:i386
3.link /LIBPATH:../../Lib -nod -nologo -debug:full -dll #msgRout.link -out:msgRout.dll
But the dll I got cannot be loaded on X64 application. it required a 64 bit dll.
So here is my question:
Can I get a 64 bit dll with vc 6.0?
Using only above 3 commands alike, how can I get 64 bit dll?
Many GREAT THANKS!!!
Allan
Visual C++ 6.0 does not include 64-bit compiler/libraries. You will need either a more recent version of Visual C++ or a Windows Platform SDK that has the 64-bit support. The earliest one is the Windows Server 2003 Platform SDK.
Once you have that installed, cl /? and link /? will have info on how to build 64-bit apps.
Update: If you have VS2005, you can build 64-bit binaries with the x86-amd64 cross-compiler (a 32-bit cl.exe that produces 64-bit code) or with the x64 compiler (a 64-bit cl.exe). To do that, you need to:
Make sure you've installed the 64-bit tools support during VS installation.
Open a command line and set it for x86-amd64 builds using C:\Program Files\Microsoft Visual Studio 8\VC\Vcvarsall.bat x86_amd64 or
(on 64-bit Windows) Open an x64 command line and set it for 64-bit builds using C:\Program Files\Microsoft Visual Studio 8\VC\Vcvarsall.bat amd64.
Once you do that, you should be able to use the same command line as above (with tcouple small changes - for cl you'll have to define /D:X64=1 or /D_AMD64_ and for link you'll have to change the /machine:x86 to /machine:x64) to produce 64-bit version of your program.
Here are some links with more information:
Installing Visual Studio 64-bit Components
HowTo: Enable a 64-Bit Visual C++ Toolset at the Command Line
Use Visual Studio to build 64-bit application
64-bit Applications
Seven Steps of Migrating a Program to a 64-bit System
You cannot. Microsoft does not have time machines.
i have a VS05 C++ (MFC) project which uses HtmlHelp (function HTMLHelpA, linked from HmleHelp.lib, which came from HTML HElp Workshop v1.4). the 32-bit version compiles and links fine.
the 64-bit version compiles fine, but gets an "unresolved external" error on HTMLHelpA, when linking.
so, my question is simple: is there a way to use HTMLHelp in x64?
If you download the latest Windows SDK (6.0A), it contains both x86 and x64 versions of this library.