Building ISMRMRD with GE's libraries

[roopchansinghv]

While trying to build ge_to_ismrmrd, I faced the following error multiple times.

I remember from your previous reply that I need to build ISMRMRD and GE Converter with the boost and hdf5 of Orchestra. I have been able to do so for hdf5 with the documentation provided. For boost however, it doesn't work. I have tried the solution provided in the documentation(https://github.com/ismrmrd/ge_to_ismrmrd, Step 5). I also looked upon this link: https://github.com/NHLBI-MR/ISMRM2019_demo/tree/master/GE_converter_demo/ge_to_ismrmrd_converter. I noticed they use a path while building: cmake -D Boost_INCLUDE_DIR=$SDKTOP/include/recon/3p/Linux/boost_1_55_0_dev_linux64/include/ -D CMAKE_INSTALL_PREFIX=$ISMRMRD_HOME -D HDF5_USE_STATIC_LIBRARIES=yes .. However I couldn't find a directory linux under Orchestra libray:

If could kindly guide me in this, it'd really helpful! Thank you in advance!

_Originally posted by @RitiP in https://github.com/ismrmrd/ge_to_ismrmrd/issues/16#issuecomment-951599325_

[roopchansinghv]

The above post details 2 separate issues. I'll address the 2nd issue first, as that's simpler.

The repository you referred to from the ISMRMRD and Gadgetron class uses an older version of the GE converter. From the date of that repository (almost 3 years ago) I would say that version of the GE converter used Orchestra version 1.7-1. In that version, GE had a different layout in the Orchestra environment, which is the reason you are seeing the above issue. We try to keep the converter current with the latest version of Orchestra, as Orchestra keeps back compatibility, so when upgrading - you shouldn't lose any functionality. If you swap out that version used in the class with the current converter, conversion should still work. The command line you will need to use will look a bit different as we changed options. The 2 different versions of the README should provide details on this.

And finally - the first issue you mentioned indicates your system does not have TLS installed in a way that the CMake process can find "libtls.so" in the library. On the Linux system I use most (openSUSE), I have a "libtls17" package installed, that provides "/usr/lib64/libtls.so". You most likely need to do something similar for the system you are working on.

[RitiP]

Hi @roopchansinghv ,

Thank you for your detailed answer. I have been able to install libtls.so and the build process has moved past the error posted previously. However, I have encountered new errors(in the image below):

I think these errors are due to the linker not being able to find these functions/variables(whose names may have changed due to version difference). Currently I'm using the openssl tar file provided in the documentation. However, I noticed that it is mentioned in the documentation to use OpenSSL version 1.0 and the tar shared in the ReadMe file has a version of 1.1.1k. Can this be a possible reason for the errors that I'm encountering? Thanks in advance !

[roopchansinghv]

If you are familiar with the "nm" tool, and if the developer didn't strip away the symbol table from the library, you can see if the library you are linking against has those functions.

OpenSSL will deprecate functions over time, as older encryption algorithms either become weaker or get broken, so it is a bit of a "cat and mouse" game to see which functions you would need to enable to find all of the symbols you would need to successfully build.

One other thing to possibly check here - likely your base Linux system already has a "libssl.so" library. You should try to make sure that if you are using a custom built OpenSSL library to support compiling for Orchestra, that your custom library shows up in a location in your "LD_LIBRARY_PATH" variable, before the one from the system.

[RitiP]

Hi @roopchansinghv ,

I have been successful in setting up the GE environment. Please feel free to close the issue. Thank you for your help in debugging! Appreciate it!