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

This topic has 2 replies, 2 voices, and was last updated 5 years, 1 month ago by Anonymous.

Viewing 2 reply threads

Author

Posts
- November 6, 2019 at 5:04 am #3293
  Anonymous
  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.
- November 6, 2019 at 3:50 pm #15047
  Anonymous
  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.
- November 14, 2019 at 8:03 am #15057
  Anonymous
  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.
Author

Posts

Viewing 2 reply threads

You must be logged in to reply to this topic.