# Linux Ubuntu build is missing Dynamically Linked Libraries (fail during unit test)

3 posts / 0 new
Linux Ubuntu build is missing Dynamically Linked Libraries (fail during unit test)
#1

Hello,

I've installed Rosetta 3.11 for Linux ubuntu 16.04 without any failure.

However, I encountered some missing binaries after running unit tests. This is the general command I use for the unit test.

python scons.py -j #numproc mode=debug cat=test

The snippet below is the output returned from the unit test.

scons: Building targets ...
g++ -o build/test/debug/linux/4.15/64/x86/gcc/5.4/default/ObjexxFCL.test -Wl,-rpath=/data/home/baverso/datadrive/Rosetta/rosetta_bin_linux_2019.35.60890_bundle/main/source/build/src/debug/linux/4.15/64/x86/gcc/5.4/default -Wl,-rpath=/data/home/baverso/datadrive/Rosetta/rosetta_bin_linux_2019.35.60890_bundle/main/source/build/external/debug/linux/4.15/64/x86/gcc/5.4/default build/test/debug/linux/4.15/64/x86/gcc/5.4/default/ObjexxFCL/ObjexxFCL.cxxtest.o -Lexternal/lib -Lbuild/src/debug/linux/4.15/64/x86/gcc/5.4/default -Lbuild/external/debug/linux/4.15/64/x86/gcc/5.4/default -L/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64_lin/gcc4.7 -L/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin -L/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin -L/usr/local/cuda/lib64 -L/usr/local/cuda/extras/CUPTI/lib64 -L/usr/lib -L/usr/local/lib -lutility -lObjexxFCL -lz -lcppdb -lsqlite3 -lcifparse -lxml2 -lzmq

/usr/bin/ld: cannot find -lutility
/usr/bin/ld: cannot find -lObjexxFCL
/usr/bin/ld: cannot find -lcppdb
/usr/bin/ld: cannot find -lsqlite3
/usr/bin/ld: cannot find -lcifparse
collect2: error: ld returned 1 exit status

(Please note that there are approximately 30 more ld type binaries that could not be find associated with dynamic linking libraries)

I'm not quite sure where to find, how to make, and where to place these missing libraries (e.g. -lutility, -lObjexxFCL, -lcppdb...).

I understand that the -l is a prefix for lib, and so I've tried command whereis to locate libutility for example, but nothing is returned.

I've also read that ld is a dynamic linking program, linking binaries from other paths to Rosetta.

This is my \$LD_LIBRARY_PATH.

/opt/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64_lin/gcc4.7:/opt/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64_lin::/usr/local/cuda/lib64:/usr/local/cuda/extras/CUPTI/lib64/

I've also run ldconfig , but I'm not really sure what steps to take next from there.
Any advice regarding how to resolve all of these missing binaries is much appreciated! Thank you.

Category:
Post Situation:
Tue, 2019-11-05 21:04
denatured

If you've downloaded the pre-compiled version of Rosetta, that's been compiled with the extras=static option in release mode. As such, the libraries for a "default" compile in debug mode (which is what you're asking for with that scons command) aren't present. You would have to compile them separately.

But honestly, I wouldn't bother. The unit tests are mainly there for developers, to make sure that they haven't broken anything during changing the code. They're not all that useful for someone who is just interested in using Rosetta. We run the unit tests before release, and don't release if things are broken, so there's nothing about the code which would change which would result in a unit test failure.

The best you could hope for is that running the unit tests might catch a compilation failure, but since the different styles of compilation are different, running the unit tests for a default debug mode compile won't tell you anything about a static release mode compile. Even building and running the unit tests in static release mode won't necessarily tell you anything more than simply running Rosetta will -- It would be an especially odd compilation error which wouldn't lead to odd crashes, but would show up in the unit tests.

If you can use the programs in the bin/ directory without any odd crashes, and you're not doing any development, I think you don't need to worry about running the unit tests.

Wed, 2019-11-06 07:50
rmoretti

Hi rmoretti,

Thanks for your response. I've moved past attempting a unit test and you're response is entirely correct, the dynamic linking should work from here.

Thu, 2019-11-14 00:03
denatured