I have a C-File that I wanna compile in Matlab with MS Visual Studio 10.
For that I use the following command:
mex -v test.c
The output that I get after compilation is the following:
test.c
Contents of C:\Temp\mex_kpuu4t\mex_tmp.rsp:
C:\Temp\mex_kpuu4t\test.obj
--> link /out:"test.mexw64" /dll /export:mexFunction /MAP /LIBPATH:"C:\Program Files\MATLAB\R2011a\extern\lib\win64\microsoft" libmx.lib libmex.lib libmat.lib /implib:"C:\Temp\mex_kpuu4t\templib.x" /MACHINE:X64 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib #C:\Temp\mex_kpuu4t\mex_tmp.rsp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Temp\mex_kpuu4t\test.obj
LINK : fatal error LNK1104: cannot open file 'test.mexw64'
C:\PROGRA~1\MATLAB\R2011A\BIN\MEX.PL: Error: Link of 'test.mexw64' failed.
Anyone an idea what could go wrong here? The interesting thing is, that the test.obj file seems not to be written to the temp folder, could that be the issue here?
Many thanks!
Maybe you called "test" from a previously compiled mex? If yes, it might still be loaded to Matlab's memory, and cannot be overwritten. Try:
clear mex
and then compile again.
Related
I need to analyze exactly how MSBuild builds a C++ project, in order to rebuild it in a different way with a different toolchain. At the moment, my main strategy for doing this is to run msbuild -fl to ask it to log its actions, then I can try to analyze the resulting msbuild.log. The compile steps in this seem clear enough, but I am still trying to figure out the linking steps.
When I use Visual Studio 2022 to create a skeleton console application, the linking step is recorded in msbuild.log as
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\olivine\test\ConsoleApplication1\x64\Debug\ConsoleApplication1.exe" /INCREMENTAL /ILK:"x64\Debug\ConsoleApplication1.ilk" /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\olivine\test\ConsoleApplication1\x64\Debug\ConsoleApplication1.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\olivine\test\ConsoleApplication1\x64\Debug\ConsoleApplication1.lib" /MACHINE:X64 /pdbthreads:4 x64\Debug\ConsoleApplication1.obj
that is, a lot of options, plus the name of the object file (the skeleton project only has one object file). That seems straightforward.
Now trying the same thing again on a skeleton desktop application:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\olivine\test\Project1\x64\Debug\Project1.exe" /INCREMENTAL /ILK:"x64\Debug\Project1.ilk" /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:\olivine\test\Project1\x64\Debug\Project1.pdb" /SUBSYSTEM:WINDOWS /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:\olivine\test\Project1\x64\Debug\Project1.lib" /MACHINE:X64 /pdbthreads:4 x64\Debug\Project1.res
x64\Debug\Project1.obj
Again, the skeleton project only has one object file. This time, it is not placed at the end of the link command, but on a separate line after the link command. Inspection of msbuild.log for a real project suggests this pattern is repeated when there are multiple object files; they are mentioned after the link command, one per line.
What's up with this? Why the difference in output format between the two projects? And how exactly does MSBuild obtain the list of object files and communicate it to the linker?
I've compiled boost using:
b2.exe link=shared runtime-link=shared address-model=32 variant=release --layout=system --stagedir=./stage/win32
I'm loading boost components to CMake myself, specifically:
find_path(Boost_INCLUDE_DIR NAMES boost/config.hpp PATHS ${CMAKE_CURRENT_SOURCE_DIR}/../external/boost_1_69_0)
message("${Boost_INCLUDE_DIR}")
add_library(Boost INTERFACE IMPORTED GLOBAL)
set_target_properties(Boost PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
find_library(Boost_filesystem_LIBRARY NAMES boost_filesystem PATHS ${CMAKE_CURRENT_SOURCE_DIR}/../external/boost_1_69_0/stage/win32/lib)
message("${Boost_filesystem_LIBRARY}")
add_library(Boost_filesystem UNKNOWN IMPORTED GLOBAL)
set_target_properties(Boost_filesystem PROPERTIES INTERFACE_INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIR})
set_target_properties(Boost_filesystem PROPERTIES IMPORTED_LOCATION ${Boost_filesystem_LIBRARY})
target_link_libraries(Boost INTERFACE Boost_filesystem)
When invoking CMake:
C:/bla/SW/cmake-template/external/boost_1_69_0
C:/bla/SW/cmake-
template/external/boost_1_69_0/stage/win32/lib/boost_filesystem.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/bla/SW/cmake-template/build-windows
And last,
Link:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\
bin\HostX86\x86\link.exe /ERRORREPORT:QUEUE /OUT:"C:\bla\SW\cmake-template\build-windows
\mylib\Debug\mylib.dll" /INCREMENTAL /NOLOGO ..\myotherlib\Debug\myotherlib.lib "C:\bla\
SW\cmake-template\external\boost_1_69_0\stage\win32\lib\boost_filesystem.lib" kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib
advapi32.lib /DEF:"C:/bla/SW/cmake-template/build-windows/mylib/mylib.dir/Debug/exports.
def" /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PD
B:"C:/bla/SW/cmake-template/build-windows/mylib/Debug/mylib.pdb" /SUBSYSTEM:CONSOLE /TLB
ID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/bla/SW/cmake-template/build-windows/mylib/Debug/
mylib.lib" /MACHINE:X86 /SAFESEH /machine:X86 /DLL mylib.dir\Debug\mylib.obj
LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc141-mt-gd-x32-1_69.lib' [
C:\bla\SW\cmake-template\build-windows\mylib\mylib.vcxproj]
I don't get it, how come it's trying to link to libboost_filesystem-vc141-mt-gd-x32-1_69.lib and not to boost_filesystem.lib?
That link comes from the auto-ink feature of some of the Boost libraries. You can either adjust the auto-link to use the appropriate naming see macros for controlling this in Boost Config library. Or you can turn off the auto-linking with the BOOST_ALL_NO_LIB macro mentioned also in the Boost Config docs.
I've used the answer here with success on previous installations but hitting a roadblock this time: How to install SIP & PyQT on windows 7
I get an error on the nmake step (see below):
C:\source>cd sip-4.19.9
C:\source\sip-4.19.9>python configure.py
This is SIP 4.19.9.dev1804161501 for Python 2.7.14 on win32.
The SIP code generator will be installed in c:\python27.
The sip module will be installed in c:\python27\Lib\site-packages.
The sip.pyi stub file will be installed in c:\python27\Lib\site-packages.
The sip.h header file will be installed in c:\python27\include.
The default directory to install .sip files in is c:\python27\sip.
Creating siplib\sip.h...
Creating siplib\siplib.c...
Creating siplib\siplib.sbf...
Creating sipconfig.py...
Creating top level Makefile...
Creating sip code generator Makefile...
Creating sip module Makefile...
C:\source\sip-4.19.9>"C:\Qt\5.10.0\msvc2015\bin\qtenv2.bat"
Setting up environment for Qt usage...
Remember to call vcvarsall.bat to complete environment setup!
C:\Qt\5.10.0\msvc2015>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
C:\Qt\5.10.0\msvc2015>cd \source\sip-4.19.9
C:\source\sip-4.19.9>nmake
Microsoft (R) Program Maintenance Utility Version 14.00.24234.1
Copyright (C) Microsoft Corporation. All rights reserved.
cd sipgen
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"
Microsoft (R) Program Maintenance Utility Version 14.00.24234.1
Copyright (C) Microsoft Corporation. All rights reserved.
cd siplib
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"
Microsoft (R) Program Maintenance Utility Version 14.00.24234.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl -c -nologo -Zm200 -Zc:wchar_t- -O2 -MD -W3 -DNDEBUG -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -I. -Ic:\python27\include -Fo #C:\Users\suzanne\AppData\Local\Temp\nmB36B.tmp
siplib.c
apiversions.c
descriptors.c
qtlib.c
threads.c
objmap.c
voidptr.c
array.c
int_convertors.c
Generating Code...
cl -c -nologo -Zm200 -Zc:wchar_t- -O2 -MD -W3 -w34100 -w34189 -DNDEBUG -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -I. -Ic:\python27\include -Fo #C:\Users\suzanne\AppData\Local\Temp\nmB8AB.tmp
bool.cpp
link /NOLOGO /DYNAMICBASE /NXCOMPAT /DLL /MANIFEST /MANIFESTFILE:sip.pyd.manifest /SUBSYSTEM:CONSOLE /INCREMENTAL:NO /OUT:sip.pyd #C:\Users\suzanne\AppData\Local\Temp\nmB939.tmp
Creating library sip.lib and object sip.exp
mt -nologo -manifest sip.pyd.manifest -outputresource:sip.pyd;2
'mt' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'mt' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Figured it out...
mt.exe part of Visual Studio's Windows SDK, which wasn't installed. Went back and installed it through Get Tools and Features.
Then found \x86\mt.exe and added it to path.
I want to build an x86 Windows application on my x64 Windows machine.
I use CMake, Ninja, clang-cl, lld-link and the VS Build Tools 2017 with the following CMakeLists
cmake_minimum_required(VERSION 3.9)
project(Test CXX)
add_library(TestLib STATIC "")
target_include_directories(TestLib
PUBLIC
TestLib/inc
)
target_sources(TestLib
PRIVATE
TestLib/src/Flop.cpp
TestLib/src/testClass.cpp
)
add_executable(Test "")
target_sources(Test
PRIVATE
src/main.cpp
)
target_link_libraries(Test
TestLib
)
My setup works fine for x64 applications. I initialise the build environment with vcvars64 and call cmake with
cmake -G Ninja -DCMAKE_CXX_COMPILER:PATH="C:\MeineProgramme\LLVM\bin\clang-cl.exe" -DCMAKE_LINKER:PATH="C:\MeineProgramme\LLVM\bin\lld-link.exe"
This results in perfectly fine ninja build files and produces a functional executable.
If I want to build an x86 application, CMake failes to detect the build environment. I initialise the build environment with vcvars32 or vcvarsamd64_x86 and use the same command as above to invoke CMake. This results in errors during the detection of the build environment.
The CMake error log has the following content
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: C:/MeineProgramme/LLVM/bin/clang-cl.exe
Build flags:
Id flags:
The output was:
1120
LINK : error LNK2001: Nicht aufgelöstes externes Symbol "mainCRTStartup".
C:\MeineProgramme\Visual_Studio\2017\BuildTools\VC\Tools\MSVC\14.11.25503\lib\x86\libcmt.lib : warning LNK4272:Bibliothekcomputertyp "x86" steht in Konflikt mit dem Zielcomputertyp "x64"
CMakeCXXCompilerId.exe : fatal error LNK1120: 1 nicht aufgelöste Externe
clang-cl.exe: error: linker command failed with exit code 1120 (use -v to see invocation)
Determining if the CXX compiler works failed with the following output:
Change Dir: D:/Dateien/Downloads/Test/build/CMakeFiles/CMakeTmp
Run Build Command:"C:/MeineProgramme/Ninja/bin/ninja.exe" "cmTC_e2ed5"
[1/2] Building CXX object CMakeFiles\cmTC_e2ed5.dir\testCXXCompiler.cxx.obj
[2/2] Linking CXX executable cmTC_e2ed5.exe
FAILED: cmTC_e2ed5.exe
cmd.exe /C "cd . && C:\MeineProgramme\CMake\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_e2ed5.dir --manifests -- C:\MeineProgramme\LLVM\bin\lld-link.exe /nologo CMakeFiles\cmTC_e2ed5.dir\testCXXCompiler.cxx.obj /out:cmTC_e2ed5.exe /implib:cmTC_e2ed5.lib /pdb:cmTC_e2ed5.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\MeineProgramme\LLVM\bin\lld-link.exe /nologo CMakeFiles\cmTC_e2ed5.dir\testCXXCompiler.cxx.obj /out:cmTC_e2ed5.exe /implib:cmTC_e2ed5.lib /pdb:cmTC_e2ed5.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_e2ed5.dir/intermediate.manifest CMakeFiles\cmTC_e2ed5.dir/manifest.res" failed (exit code 1) with the following output:
C:\MeineProgramme\LLVM\bin\lld-link.exe: warning: <root>: undefined symbol: mainCRTStartup
error: link failed
ninja: build stopped: subcommand failed.
As far as I understand, the problem is that CMake passes /machine:x64 to the linker.
Which modifications should I make to the CMake invocation or the CMakeLists to solve this problem?
Any help is very much appreciated. Thank you guys :-)
CMake Issue #16259: "Ninja generator fails with clang-cl when mixing 64/32 bit clang and Visual Studio Environment" suggests utilizing environment variables:
The Ninja generator requires that the environment already be configured for the compiler to produce the desired target. You need to do
>set CC=clang-cl
>set CFLAGS=-m32
>set CXX=clang-cl
>set CXXFLAGS=-m32
to tell CMake how to invoke the compiler for the desired target.
I try to compile some stuff with Matlab, and during the process Matlab should create some
temporary folders. Unfortunately, for some reason, this is not happening and therefore the compilation fails. I executed Matlab with Administrator rights, but the problems reminds. I am not sure if their is some other problem with the User Access Control under Windows 7. Could anyone give me some instructions of how I can make sure that Matlab has all the privileges to write temporary files?
EDIT:
Actually it is mex file compilation, so the error could also come from the VS compiler:
--> cl /c /Zp8 /GR /W3 /EHs /D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_DEPRECATE /D_SECURE_SCL=0 /DMATLAB_MEX_FILE /nologo /MD /FoC:\Temp\mex_OmN_AO\test.obj -I"C:\Program Files\MATLAB\R2011a\extern\include" -I"C:\Program Files\MATLAB\R2011a\simulink\include" /O2 /Oy- /DNDEBUG -DMX_COMPAT_32 vcd_count_transitions.c
test.c
Contents of C:\Temp\mex_OmN_AO\mex_tmp.rsp:
C:\Temp\mex_OmN_AO\test.obj
--> link /out:"test.mexw64" /dll /export:mexFunction /MAP /LIBPATH:"C:\Program Files\MATLAB\R2011a\extern\lib\win64\microsoft" libmx.lib libmex.lib libmat.lib /implib:"C:\Temp\mex_OmN_AO\templib.x" /MACHINE:X64 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib #C:\Temp\mex_OmN_AO\mex_tmp.rsp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Temp\mex_OmN_AO\test.obj
LINK : fatal error LNK1104: cannot open file 'test.mexw64'
C:\PROGRA~1\MATLAB\R2011A\BIN\MEX.PL: Error: Link of 'test.mexw64
I would expect after the compilation fails, there should be C:\Temp\mex_OmN_AO directory,
but there is nothing in my TEMP folder.
Many thanks for your help!