NanoSim / Porto

The Porto multi-scale framework
GNU General Public License v3.0
3 stars 3 forks source link

improvement of compilation setup #8

Open sradl1981 opened 7 years ago

sradl1981 commented 7 years ago

On a OpenSUSE Leap 42.2 system the following problem occurs there are issues related to libbson and libmongoc when compiled during the soft5 make process (activation of compilation via ccmake ../soft5, switche "BUILD_MONGOC"; binaries are placed into $HOME/NanoSim/build-soft5/usr/lib64/). When using the system libraries for libbson and libmongoc on OpenSUSE, other problems occured, so this is not a solution either.

While everything works fine for

NanoSim/soft5/storage/test/plugins/mongo2

this is not the case for

NanoSim/soft5/porto/src/dft-prepare

Thus, the storage-plugin-mongo-test2 seems to link to the correct libraries: ldd /home/sradl/NanoSim/build-soft5/storage/test/plugins/mongo2/storage-plugin-mongo-test2 linux-vdso.so.1 (0x00007ffef4e8a000) libsoft-storage-mongo.so => /usr/local/soft5/lib64/libsoft-storage-mongo.so (0x00007fc1fa893000) libbson-1.0.so.0 => /home/sradl/NanoSim/build-soft5/usr/lib64/libbson-1.0.so.0 (0x00007fc1fa660000) libmongoc-1.0.so.0 => /usr/local/soft5/lib64/libmongoc-1.0.so.0 (0x00007fc1fa405000) libsoft-kernel.so => /usr/local/soft5/lib64/libsoft-kernel.so (0x00007fc1fa1ce000) libQt5Network.so.5 => /usr/lib64/libQt5Network.so.5 (0x00007fc1f9e77000) libQt5Script.so.5 => /usr/lib64/libQt5Script.so.5 (0x00007fc1f99fa000) libQt5Concurrent.so.5 => /usr/lib64/libQt5Concurrent.so.5 (0x00007fc1f97f3000) libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00007fc1f9134000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fc1f8dab000) libm.so.6 => /lib64/libm.so.6 (0x00007fc1f8aae000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc1f8897000) libc.so.6 => /lib64/libc.so.6 (0x00007fc1f84f4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc1f82d7000) librt.so.1 => /lib64/librt.so.1 (0x00007fc1f80cf000) libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fc1f7e63000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fc1f7a07000) libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007fc1f77ea000) libz.so.1 => /lib64/libz.so.1 (0x00007fc1f75d4000) libicui18n.so.52.1 => /usr/lib64/libicui18n.so.52.1 (0x00007fc1f71c0000) libicuuc.so.52.1 => /usr/lib64/libicuuc.so.52.1 (0x00007fc1f6e41000) libpcre16.so.0 => /usr/lib64/libpcre16.so.0 (0x00007fc1f6bdb000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fc1f69d7000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fc1f66c7000) /lib64/ld-linux-x86-64.so.2 (0x00007fc1fab06000) libicudata.so.52.1 => /usr/lib64/libicudata.so.52.1 (0x00007fc1f64c6000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc1f6257000)

...the dft-prepare application somehow does not directly link the library, and hence if not in place will result in SEG FAULT if executed ldd /usr/local/soft5/bin/dft-prepare linux-vdso.so.1 (0x00007fff58b0c000) libsoftc.so => /usr/local/soft5/lib64/libsoftc.so (0x00007fa80c7de000) libsoft-kernel.so => /usr/local/soft5/lib64/libsoft-kernel.so (0x00007fa80c5a7000) libQt5Network.so.5 => /usr/lib64/libQt5Network.so.5 (0x00007fa80c250000) libQt5Script.so.5 => /usr/lib64/libQt5Script.so.5 (0x00007fa80bdd3000) libQt5Concurrent.so.5 => /usr/lib64/libQt5Concurrent.so.5 (0x00007fa80bbcc000) libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00007fa80b50d000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fa80b184000) libm.so.6 => /lib64/libm.so.6 (0x00007fa80ae87000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa80ac70000) libc.so.6 => /lib64/libc.so.6 (0x00007fa80a8cd000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa80a6b0000) libz.so.1 => /lib64/libz.so.1 (0x00007fa80a49a000) libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007fa80a22e000) libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007fa809dd2000) librt.so.1 => /lib64/librt.so.1 (0x00007fa809bca000) libicui18n.so.52.1 => /usr/lib64/libicui18n.so.52.1 (0x00007fa8097b6000) libicuuc.so.52.1 => /usr/lib64/libicuuc.so.52.1 (0x00007fa809437000) libpcre16.so.0 => /usr/lib64/libpcre16.so.0 (0x00007fa8091d1000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa808fcd000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fa808cbd000) /lib64/ld-linux-x86-64.so.2 (0x00007fa80ca26000) libicudata.so.52.1 => /usr/lib64/libicudata.so.52.1 (0x00007fa808abc000) libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fa80884d000)

sradl1981 commented 7 years ago

We need a useCase0 that checks if all entities are in place for a specific set of useCases. "make test" is one step, but this will not be routinely used by users.

tankefugl commented 7 years ago

We need an error message in the case where it cannot load libraries dynamically, instead of SEGV