Closed KrisThielemans closed 3 years ago
With CMake 3.9-rc4 I successfully built with pre-downloaded Boost, HDF5 and FFTW (as per the wiki) and at commit 0eabb888fd22412a1fc418063c08ed67c9adc463
(command lines were in Powershell)
cd C:\Users\krisf\Documents\devel\SIRF-SuperBuild-CMake3.9-64
~/Documents/devel\CMake-Build\INSTALL\bin/cmake -DBOOST_ROOT=C:/Users/krisf/Documents/devel/boost_1_63_0 -DUSE_SYSTEM_Boost=On -DUSE_SYSTEM_HDF5=On -DCMAKE_GENERATOR_PLATFORM=x64 -DCMAKE_INSTALL_PREFIX=C:\Users\krisf\Documents\devel\SIRF-SuperBuild-CMake3.9-64/INSTALL -DUSE_SYSTEM_FFTW3=On -DFFTW3_ROOT_DIR=C:/Users/krisf/Documents/devel/fftw-3.3.5-dll64 C:/Users/krisf/Documents/devel/SIRF-SuperBuild
Some difficulties encountered with HDF5:
c:\aroot
folder for zlib etc)HDF5_DIR
. This might be due to a bug in FindHDF5.cmake (it only goes for the config version if HDF5_ROOT
is set) but even when I try to fix that, it still doesn't find it.H5_BUILT_AS_DYNAMIC_LIB
to HDF5_DEFINITIONS
when in Module-mode. We could fix that (see https://gitlab.kitware.com/cmake/cmake/merge_requests/1023)HDF5_DEFINITIONS
, ISMRMRD/CMakeLists.txt (and Gadgetron) does not use it yet (see https://github.com/ismrmrd/ismrmrd/pull/92)Summary:
Just checked that adding -DHDF5_USE_STATIC_LIBRARIES=1
still needs a change to FindHDF5 as the relevant lines there are only enabled on Unix. Fix is in
https://gitlab.kitware.com/cmake/cmake/merge_requests/1023
So, sadly it seems that unless we can force CMake to find our Config-install of HDF5 (see https://gitlab.kitware.com/cmake/cmake/issues/17029), we can only build with an installed HDF5 in Program Files (at least until FindHDF5.cmake gets fixes)
Started testing with CMake 3.10.1 (which has the relevant fixes for FindHDF5.cmake
).
Current problems:
CMAKE_INSTALL_PREFIX
was not reset from the default (should normally have been set ok)USE_SYSTEM_HDF5
was not correctly honoured (When I ran CMake, it said it was using the system version, but Visual Studio went ahead and downloaded source and compiled anyway).library machine type 'X86' conflicts with target machine type 'x64'
Items 2 and 3 might have been because I ran CMake a few times (with deleting the cache and without) before settling on USE_SYSTEM_HDF5=On
. It's strange/undesirable though. Will need to check again later.
confirmed that when deleting the cache, configuring, and then clicking USE_SYSTEM_HDF5
does work as expected (also for CMAKE_INSTALL_PREFIX
). Not sure how to reproduce the above problems 2 and 3 so I am going to ignore them...
CTest fails because config option isn't passed on:
ctest -VV -C Release
...
test 1
Start 1: SIRF_TESTS
1: Test command: "C:\Program Files\CMake\bin\ctest.exe" "test"
...
1: Start 1: PET_TEST1
1: Test not available without configuration. (Missing "-C <config>"?)
1: 1/3 Test #1: PET_TEST1 ........................***Not Run 0.00 sec
...
Can we add this option on other systems?
Going to the relevant subdir, PET tests work after setting PYTHONPATH
! In Powershell
cd SIRF-prefix\src\SIRF-build\src\xSTIR
Env:PYTHONPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python"
ctest -VV -C Release
...
100% tests passed, 0 tests failed out of 1
MR tests fail with error
1: Traceback (most recent call last):
1: File "fully_sampled.py", line 22, in <module>
1: from pGadgetron import *
1: File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pGadgetron.py", line 41, in
<module>
1: import pygadgetron
1: File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pygadgetron.py", line 17, in
<module>
1: _pygadgetron = swig_import_helper()
1: File "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python\pygadgetron.py", line 16, in
swig_import_helper
1: return importlib.import_module('_pygadgetron')
1: File "C:\Users\krisf\Anaconda2\lib\importlib\__init__.py", line 37, in import_module
1: __import__(name)
1: ImportError: DLL load failed: The specified module could not be found.
This means that a DLL isn't in the Path. Sadly, Windows doesn't say which one. Obvious candidate is the ISMRMRD DLL but the following didn't help
$env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\bin"
@evgueni-ovtchinnikov , do you know how to set the PATH correctly?
Compilation problems should be fixed with #64.
Still need to fix above ctest and DLL problems, and also create .bat
and .PS1
files with appropriate settings. @evgueni-ovtchinnikov and @paskino can you find the correct settings and then creating the configure file?
Currently tested with USE_SYSTEM_BOOST=ON
only, but USE_SYSTEM_FFTW
ON/OFF
, USE_SYSTEM_HDF5
`ON/OFF'.
old version of HDF5 (1.8.15) with out-of-date conda gives
LINK : fatal error LNK1181: cannot open input file 'C:\aroot\stage\Library\lib\z.lib' [C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\ISMRMRD-prefix\src\ISMRMRD-build\ismrmrd.vcxproj]
This is resolved with a conda update hdf5
.
Regarding ctest, need to call ctest in the SIRF-build with -C ${CMAKE_CFG_INTDIR}
probably. However, this might then fail when using Makefiles as CMAKE_CFG_INTDIR
might be set to .
as opposed to empty (I checked that on the VM, both ctest -C
and ctest -C .
work fine though, so this should be safe). @rijobro, can you try this on Mac?
A few more fixes have been incorporated. All the ctest
problems have now been fixed.
The above mentioned DLL problem was related to both FFTW and boost. dumpbin
(part of the VS Toolkit) gave
dumpbin /dependents _pygadgetron.pyd
boost_filesystem-vc140-mt-1_63.dll
boost_thread-vc140-mt-1_63.dll
boost_system-vc140-mt-1_63.dll
ismrmrd.dll
libfftw3f-3.dll
hdf5.dll
....
where I cut system libraries. Any DLLs in INSTALL/bin
(such as ismrmd.dll
) would be picked up if that's included in the PATH. I had to do the following (in Powershell):
$Env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\bin"
$Env:Path += ";C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\FFTW"
$Env:Path += ";c:/Users/krisf/Documents/devel/boost_1_63_0/lib64-msvc-14.0/"
$Env:PYTHONPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\python"
$Env:MATLABPATH = "C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\matlab"
(The FFTW line would not be necessary when using a system-version presumably).
As an alternative, I guess we could copy the libraries in bin
(ugly) or force static linking (probably best really).
Sadly, I still get a python crash when just loading an MR.AcquisitionData
object (with filename). I guess a conflict between DLLs or something.
For MATLAB, I still have problems presumably also related to DLLs
>> [notfound, warnings] = loadlibrary('mgadgetron')
Error using loadlibrary
There was an error loading the library
"C:\Users\krisf\Documents\devel\build-VC\SIRF-SuperBuild-CMAKE3.10\INSTALL\matlab\mgadgetron.mexw64"
The specified procedure could not be found.
Caused by:
Error using loaddefinedlibrary
The specified procedure could not be found.
Closing this as very outdated. Updating #197 instead
At present, most configurations will fail for Windows. Probably our best strategy is to download precompiled packages and use those.