I am trying to build tensorflow for win32 with cmake. All is fine until it hit this line:
libprotobuf.lib(descriptor.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' [A:\src\tensorflow\tensorflow\contrib\cmake\build32\proto_text.vcxproj]
Upon checking, the libprotobuf.lib is indeed built as a x64 binary.
So where should I change to make it build a win32 library?
I had the similar linking error when building 32bit tensorflow.dll.
I fixed the problem by manually changing the mangled name of ~OpDef from
??1OpDef#tensorflow##UEAA#XZ
to
??1OpDef#tensorflow##UAE#XZ
(latter I found by running "dumpbin /symbol" on op_def.pb.obj)
this problem is resolved. Apparently during building, tensorflow downloads protobuf, and the generated project file has target machine set to x64. So this was an easy fix.
Now I have encountered a new problem: during building of the pywrap_tensorflow_internal project, the following link error happened:
error LNK2001: unresolved external symbol "public: virtual __cdecl tensorflow::OpDef::~OpDef(void)"
It looks the project is using __cdecl calling convention while the ~OpDef destructor is using __thiscall. And I can't change the calling convention of a class destructor. I have no idea how this could happen.
Any idea on how to fix this calling convention mismatch issue?
Related
I'm trying to link a Windows executable that depends on a several static libraries (some of which I have built, some of which I have not). When I do the link, I get a flock of errors like:
LIBCMT.lib(mlock.obj) : error LNK2005: _unlock already defined in MSVCRT.lib(MSVCR100.dll)
which is the classic /MD vs. /MT problem (whether the C runtime is statically or dynamically linked). I tried the easy solution first, adding the linker flags
/nodefaultlib:libcmt /nodefaultlib:libcpmt
but that just gave different errors:
msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: __cdecl std::_Locinfo::~_Locinfo(void)" (??1_Locinfo#std##QEAA#XZ) already defined in gtest.lib(gtest-all.cc.obj)
gtest.lib(gtest-all.cc.obj) : error LNK2001: unresolved external symbol "private: static int std::locale::id::_Id_cnt" (?_Id_cnt#id#locale#std##0HA)
I've gone through the libraries I'm building, and as far as I can tell I'm building them all /MD. I say "as far as I can tell" because some of them are third-party libraries that come with their own makefiles so I don't have complete control over the build process..
I don't think "depends" works on libraries (only EXEs and DLLs), is there a tool that would let me look at the various libraries I'm linking in, and see which one is bringing in libcmt when I want to be using msvcrt instead?
I have had the same problem and I used dumpbin ( http://msdn.microsoft.com/en-us/library/z66yd3h6.aspx ) with /DIRECTIVES options on the libs. It will show a number of /DEFAULTLIB sections, each one is another lib that your lib try to use. Dumpbin needs to run from the Visual Studio command promt.
dumpbin /DIRECTIVES liblua52.lib
I had 100+ libs with all the solution configurations and platforms so I made a python 2.7 script (crtdisplay.py) to do it for me. It can be found on my bitbucket repository at https://bitbucket.org/vimarina/ctrlcv/src/57b7ddca15b5c7fefddcf20ffcea0633223a4bd6/crtdisplay . Put it in the root directory of your libs. Not much error checking in that code so do not be surprised if it fails :). I used Visual Studio 2010 so might fail on other versions of Visual Studio.
crtdisplay.py > info.txt
I am trying to built a .cpp file using OpenNI in Visual Studio 2012. I am using the code of the SimpleViewer sample (it is included in the OpenNI). When I try to build the .cpp file I got the error LNK2019 which it seems a problem when the compiler has to link the OpenNI library. What could be wrong?
Errors (55 in total):
> Error 1 error LNK2019: unresolved external symbol __imp__oniShutdown
> referenced in function "public: static void __cdecl
> openni::OpenNI::shutdown(void)"
> (?shutdown#OpenNI#openni##SAXXZ) C:\Develop\VisualStudioWorkspace\Projects\My
> programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
Error 2 error LNK2019: unresolved external symbol __imp__oniWaitForAnyStream referenced in function "public: static enum openni::Status __cdecl openni::OpenNI::waitForAnyStream(class openni::VideoStream * *,int,int *,int)" (?waitForAnyStream#OpenNI#openni##SA?AW4Status#2#PAPAVVideoStream#2#HPAHH#Z) C:\Develop\VisualStudioWorkspace\Projects\My programs\OpenNI2_test\OpenNI2_test\Viewer.obj OpenNI2_test
I followed all the steps described in the OpenNI website to compile a file in Visual Studio: I added all the VCC Directories and the Include and Lib environment variables. I also added OpenNI2.lib in the additional dependencies on the Linker section. I also copied the Redist files in the working directory (the directory where I have the .vcproj).
I ran into a similar issue. The sample projects wouldn't build because I was using OpenNI for x64 but the platform was set to Win32. Changing to x64 (in the properties dialog at the top) fixed it for me.
OpenNI 2.0 is not mature enough. Most of the libraries, open source codes, examples and wrappers still use OpenNI 1.5. The integration is not easy since OpenNI2 uses the Microsoft official drivers and OpenNI1.x uses the open source drivers. The 32bit version gives less problems than the 64bits but I ended up installing and working the OpenNI 1.5 and the Kinect non-official drivers.
The problem is related to the linking process. You may have wrong link path in the properties of your projects. There is solution, check this question
maybe it works in your case!
I'm having trouble to compile VTK 5.10.1 example code in Visual Studio 2010 on Windows 7 64 bit SP1.
First of all, I installed VTK using this tutorial.
No errors occured while installing VTK and the example executables like cone.exe located at C:\VTK5.10.1_cmake\bin\Release are running just fine.
In Visual Studio 2010 I started a new Win32 console application and tested the first example code from this site.
I edited the projekt properties (additional include directories, additional Library directories and additional dependencies).
The linker errors looked like that:
vtktest.obj : error LNK2019: unresolved external symbol ""public: void __thiscall vtkRenderer::AddActor(class vtkProp *)" (?AddActor#vtkRenderer##QAEXPAVvtkProp###Z)" referenced in function "_main".
Most of the the other people with the same error forgot to add the libs to the additional dependencies.
However I added all libs in the C:\VTK5.10.1_bin\lib\vtk-5.10 directory and the opengl32 library. I tried to seperate the libs by a space, a semicolon and a new line.
Then, I read that people are using the shared libraries. I'm not really familiar with dlls. I reinstalled VTK
with shared libraries options turned on and copied the resulting dlls to the System32 directory.
Now, the errors looks slightly different:
vtktest.obj : error LNK2019: unresolved external symbol ""__declspec(dllimport) public: void __thiscall vtkRenderer::AddActor(class vtkProp *)" (__imp_?AddActor#vtkRenderer##QAEXPAVvtkProp###Z)" referenced in function "_main".
Any help would be appriciated!
Nevermind, forgot to change the platform to x64 :/
I develop addons for a space flight simulator called Orbiter: http://orbit.medphys.ucl.ac.uk/
It accepts plugins as dll files. I recently made a plugin which uses the Bullet physics library as well. Its statically linked to the dll, so the bullet library is itself not a dll but compiled right into the plugin. Bullet is compiled with Multi-threaded (/MT) option for the release and Multi-threaded Debug (/MTd) for debug
Now I want to use threads from Boost. So I installed the static Boost libraries by choosing the 2 static options from the Boost Pro installer. I was able to successfully create a Win 32 application with these static libraries. The application used Multi-threaded (/MT) as well. So I know that there is no mismatch on the flags.
Yet, when I add Boost to my Orbiter dll plugin project, which also has Bullet, I get a link error :
1>------ Build started: Project: Bump, Configuration: Release Win32 ------
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(F:\Orbiter\Orbitersdk\samples\BumpThreaded\Release\Bump.dll) does not match the Linker's OutputFile property value (F:\Orbiter\Modules\Plugin\Bump.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info##AAE#ABV0##Z) already defined in LIBCMT.lib(typinfo.obj)
1>MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info##AAEAAV0#ABV0##Z) already defined in LIBCMT.lib(typinfo.obj)
1> Creating library F:\Orbiter\Orbitersdk\samples\BumpThreaded\Release\Bump.lib and object F:\Orbiter\Orbitersdk\samples\BumpThreaded\Release\Bump.exp
1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>......\Modules\Plugin\Bump.dll : fatal error LNK1169: one or more multiply defined symbols found
========== Build: 0 succeeded, 1 failed, 3 up-to-date, 0 skipped ==========
From what I read on other questions, this can be due to mismatched flags for 2 libraries being used within an application. But thats not the case here. Both Bullet and Boost are compiled with /MT.
Also boost works ok with a normal win 32 application, so why the problem when linking it statically to output a dll ?
I use visual studio 2010 express and have a windows 7 64 bit system.
Thanks for any help in advance :)
If you're only using Boost and Bullet, and these are both definitely compiled with /MT, then it must be your Bump dll itself which is using /MD.
I have a large and complicated project that is finally getting unit tests. I've built googleTest 1.6.0 locally with Visual Studio 2010, the project files built with cmake as the README specifies.
This project has many dependent libraries that are statically and dynamically linked. Many of them proprietary. All attempts to link generate 220 such errors. Here is a sampling:
msvcprtd.lib(MSVCP100D.dll) : error LNK2005: "public: void __cdecl std::_Container_base12::_Orphan_all(void)" (?_Orphan_all#_Container_base12#std##QEAAXXZ) already defined in gtest.lib(gtest-all.obj)
libcpmtd.lib(cerr.obj) : error LNK2005: "protected: char * __cdecl std::basic_streambuf >::_Gndec(void)" (?_Gndec#?$basic_streambuf#DU?$char_traits#D#std###std##IEAAPEADXZ) already defined in msvcprtd.lib(MSVCP100D.dll)
LIBCMTD.lib(setlocal.obj) : error LNK2005: _configthreadlocale already defined in MSVCRTD.lib(MSVCR100D.dll)
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library
fatal error LNK1169: one or more multiply defined symbols found
I've tried the /NODEFAULTLIB flag, and I've tried to ignore just msvcprtd.lib, MSVCRTD.lib, and LIBCMTD.lib, as suggested, but then I suffer from unresolved symbols...
Both the project and googleTest are compiled with x64, /MP, /MDd, and no /clr.
I've been playing around with compiler flags, wondering if there's some sort of version mismatch. Dumpbin, to the extent with which I understand it, hasn't hinted anything I might understand. I was hoping for an er
It looks like your question is answered in Google Talk's FAQ. Make sure all your libraries use the /MD(d) setting.
You may get a number of the following linker error or warnings if you attempt to link your test project with the Google Test library when your project and the are not built using the same compiler settings.
LNK2005: symbol already defined in object
LNK4217: locally defined symbol 'symbol' imported in function 'function'
LNK4049: locally defined symbol 'symbol' imported
The Google Test project (gtest.vcproj) has the Runtime Library option set to /MT (use multi-threaded static libraries, /MTd for debug). If your project uses something else, for example /MD (use multi-threaded DLLs, /MDd for debug), you need to change the setting in the Google Test project to match your project's.
To update this setting open the project properties in the Visual Studio IDE then select the branch Configuration Properties | C/C++ | Code Generation and change the option "Runtime Library". You may also try using gtest-md.vcproj instead of gtest.vcproj.