Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › Error running unit test executable
- This topic has 14 replies, 4 voices, and was last updated 3 years, 8 months ago by Anonymous.
-
AuthorPosts
-
-
July 5, 2017 at 5:59 am #2691Anonymous
Hello!
I was trying to test my Rosetta installation and at the begining of test I’ve got an error:
I didn’t find any solution on Rosetta Forum.
server@localhost:~$ python test/run.py
Identifying platform…
Platform found: debug/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Unit test summary
Total number of tests: 0
number tests passed: 0
number tests failed: 0
Success rate: 0%
End of Unit test summaryDone!
Please help me in this issue.
Regards
-
July 5, 2017 at 2:49 pm #13558Anonymous
I’m guessing you didn’t build the unit tests. They build separately.
scons.py -j# cat=test
Note if you only built your libraries in release mode, you’ll need to add mode=release to scons and a similar flag (I forget exactly what it is, I think it’s –mode=release) to test.py. Officially the unit tests are supposed to be built and run in debug mode. In most circumstances the release build is fine too. (The debug mode has extra checks, so sometimes stuff will pass release that fails debug).
-
July 6, 2017 at 7:52 pm #13584Anonymous
There’s also some trajectory changes due to optimization which means that things which pass debug mode will fail in release mode.
IIRC there are a small subset of tests which are known to be failing when run in release mode, but are perfectly fine when run in debug mode. These are not a concern.
-
-
July 17, 2017 at 11:14 am #13618Anonymous
Unfortunately I have the same error. Here is some output:
destrudo@ubuntu:~/rosetta_bin_linux_2017.18.59451_bundle/main/source$ python scons.py -j1 cat=test
scons: Reading SConscript files …
Running versioning script … /bin/sh: 1: git: not found
Done. (0.0 seconds)
Number of option files updated: 0
Total 3964 options.
Finished updating ResidueProperty code — no changes needed
Finished updating VariantType code — no changes needed
scons: done reading SConscript files.
scons: Building targets …
scons: `.’ is up to date.
scons: done building targets.
destrudo@ubuntu:~/rosetta_bin_linux_2017.18.59451_bundle/main/source$ python test/run.py –mode=debug
Identifying platform…
Platform found: debug/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Unit test summary
Total number of tests: 0
number tests passed: 0
number tests failed: 0
Success rate: 0%
End of Unit test summaryDone!
-
July 17, 2017 at 2:53 pm #13620Anonymous
Did you compile the Rosetta libraries in debug mode before compiling the unit tests? (e.g. plain ‘python scons.py -j1’)
Also, what does the directory tree under ~/rosetta_bin_linux_2017.18.59451_bundle//main/source/build/ look like? Is there a src/debug/linux/4.10/64/x86/gcc/6.3/default/ directory, or do you only get part way down the tree?
-
-
September 25, 2017 at 10:38 pm #13790Anonymous
I assume that “gss” in your path is a mis-typed “gcc”? I’m not familiar with gss?
In the same path – if you built the tests – where you have “src” you should also have “test”, with all the subdirectories having the same name. Is that there too?
-
September 26, 2017 at 2:57 am #13791Anonymous
Sorry about the typo, yes it was supposed to be “gcc” not “gss.” I’ve edited my previous post to correct it.
I have a “test” folder in the main/source path (next to the “src” folder). This “test” folder only has one subfolder, called “debug.” I also have another “test” folder (and another “src” folder) in the main/source/build path. This “test” folder doesn’t have a “debug” subfolder. I’m uploading a screenshot of the file structure, in case it’s helpful. Thanks for your assistance!
-
October 10, 2017 at 4:02 pm #13799Anonymous
When you run test/run.py, what does it say for “Platform found:”? Does it match the directory that exists in your build/ directory?
Are there *.test files (e.g. protocols.test core.test) in the build/test/debug/linux/4.10/64/x86/gcc/6.3/default directory?
What happens when you change into that directory and run `./core.test ScoreFunctionTest –database /path/to/Rosetta/main/database` in it (change the path to the database, as appropriate)?
-
October 14, 2017 at 9:16 pm #13809Anonymous
Hi rmoretti,
I’ll answer your questions sequentially:
1) When you run test/run.py, what does it say for “Platform found:”? Does it match the directory that exists in your build/ directory?
>>>Here are the outputs when I run ‘python test/run.py’ and ‘python test/run.py –mode=debug’. Of note, the error message given (without debug mode) is correct; the only subfolder in the build/test path is debug. There is no ‘release’ subfolder in this directory.
ajvincelli@ajvincelli-VirtualBox:~/Desktop/Rosetta/main/source$ python test/run.py
Identifying platform…
Platform found: release/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for ObjexxFCL.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Error running unit test executable for devel.test – not all tests may be availible.
Traceback (most recent call last):
File “test/run.py”, line 667, in <module>
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 661, in main
T.runUnitTests()
File “test/run.py”, line 380, in runUnitTests
with open(log_file, ‘w’) as log_file_h:
IOError: [Errno 2] No such file or directory: u’build/test/release/linux/4.10/64/x86/gcc/6.3/default/protocols.test.log’
ajvincelli@ajvincelli-VirtualBox:~/Desktop/Rosetta/main/source$ python test/run.py –mode=debug
Identifying platform…
Platform found: debug/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Unit test summary
Total number of tests: 0
number tests passed: 0
number tests failed: 0
Success rate: 0%
End of Unit test summaryDone!
2) Are there *.test files (e.g. protocols.test core.test) in the build/test/debug/linux/4.10/64/x86/gcc/6.3/default directory?
>>>Yes, both of these test files are in that directory.
3) What happens when you change into that directory and run `./core.test ScoreFunctionTest –database /path/to/Rosetta/main/database` in it (change the path to the database, as appropriate)?
>>> Here’s what I get:
ajvincelli@ajvincelli-VirtualBox:~/Desktop/Rosetta/main/source/build/test/debug/linux/4.10/64/x86/gcc/6.3/default$ ./core.test ScoreFunctionTest –database /Desktop/Rosetta/main
./core.test: error while loading shared libraries: libsqlite3.so: cannot open shared object file: No such file or directory
This error message is also true; when I search the entire Rosetta folder for ‘libsqlite3.so’ I find two files in the following paths:
Desktop/Rosetta/main/source/build/external/debug/linux/4.10/64/x86/gcc/6.3/default
Desktop/Rosetta/main/source/build/external/release/linux/4.10/64/x86/gcc/6.3/default
I’m hoping that this info sheds some light on the problem! Thank you so much for your help, I really appreciate it.
-
October 16, 2017 at 5:36 pm #13813Anonymous
Okay, the issue is that Rosetta can’t find the ‘libsqlite3.so’ files. Normally in the build process there should be a mechanism which notates their location and allows the executables to find them later.
Did you happen to move the Rosetta directory after you compiled it? If you did, the location annotation may no longer be pointing to the correct location. Even something as simple as mounting the directory (or parent directory) at a different location can cause this issue. If this is the case, recompiling at the new location can often fix the issue. You may or may not need to delete ~/Desktop/Rosetta/main/source/build/test/debug/linux/4.10/64/x86/gcc/6.3/default/*.test before recompiling to get things to properly recompile.
The other option is to simply add the ~/Desktop/Rosetta/main/source/build/external/debug/linux/4.10/64/x86/gcc/6.3/default and/or ~/Desktop/Rosetta/main/source/build/external/release/linux/4.10/64/x86/gcc/6.3/default directories (depending on which version debug/release you’re intending to use) to your LD_LIBRARY_PATH variable before running. How to do this varies based on your shell, but for something like Bash, `export LD_LIBRARY_PATH:~/Desktop/Rosetta/main/source/build/external/debug/linux/4.10/64/x86/gcc/6.3/default/` should work.
-
October 28, 2017 at 4:56 pm #13826Anonymous
Hi Rmoretti,
Okay, I deleted my Rosetta folder and started from scratch, while making notes of exactly what I did. I get the same error message! I did not move the Rosetta directory or change any of the defaults. I did not type any commands other that what you see in my notes below.
I think there must be a typo somewhere in the instructions on the website (https://www.rosettacommons.org/docs/latest/development_documentation/test/run-unit-test), because I followed them exactly (twice now!) and it doesn’t work.
Here’s the steps:
First, I followed the instructions on https://www.rosettacommons.org/demos/latest/tutorials/install_build/install_build
1) Obtained a Rosetta academic license from https://els.comotion.uw.edu/licenses/86
2) Downloaded Rosetta latest weekly release source (2017.39, 2.8 GB) from https://www.rosettacommons.org/software/academic
3) Extracted the tgz file to the Desktop, selecting the option to keep the directory structure
4) Renamed the extracted folder as “Rosetta”
5) In Terminal, typed “cd ./Desktop/Rosetta/main/source”
***Note that the website says “If you downloaded the source bundle, you can see that the bin/ directory is currently empty.” However, actually the bin/ directory does not exist in the source folder.***
6) In Terminal, typed “./scons.py -j 2 mode=release bin” and waited over 2 hours to complete, got the message “scons: done building targets.”
The first bullet point of this website says that unit tests are “are occasionally used to verify Rosetta is installed correctly.” https://www.rosettacommons.org/docs/latest/development_documentation/test/rosetta-tests
Second, I followed the instructions on https://www.rosettacommons.org/docs/latest/development_documentation/test/run-unit-test
7) Restarted Terminal, then typed “cd ./Desktop/Rosetta/main/source”
In Terminal, typed “./scons.py -j 2 mode=debug” and waited about 2 hours to complete, got the message “scons: done building targets.”
***Note that the website says “scons.py -j #numproc mode=debug” but it should say “./scons.py -j #numproc mode=debug” (following the same formatting as on the previous website, https://www.rosettacommons.org/demos/latest/tutorials/install_build/install_build) and in order to avoid the error “scons.py: command not found”
***Note that there’s also a typo on this website, “succeeed”
9) Restarted Terminal, then typed “cd ./Desktop/Rosetta/main/source”
10) In Terminal, typed “./scons.py -j 2 mode=debug cat=test” and waited less than 2 hours to complete, got the message “scons: done building targets.”
***Note that the website says “scons.py -j #numproc mode=debug cat=test” but it should say “./scons.py -j #numproc mode=debug cat=test” (following the same formatting as on the previous website, https://www.rosettacommons.org/demos/latest/tutorials/install_build/install_build) and in order to avoid the error “scons.py: command not found”
11) Restarted Terminal, then typed “cd ./Desktop/Rosetta/main/source”
12) In Terminal, typed “python test/run.py” and got the message:
Identifying platform…
Platform found: release/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for ObjexxFCL.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Error running unit test executable for devel.test – not all tests may be availible.
Traceback (most recent call last):
File “test/run.py”, line 667, in <module>
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 661, in main
T.runUnitTests()
File “test/run.py”, line 380, in runUnitTests
with open(log_file, ‘w’) as log_file_h:
IOError: [Errno 2] No such file or directory: u’build/test/release/linux/4.10/64/x86/gcc/6.3/default/protocols.test.log’
13) In Terminal, typed “python test/run.py –mode=debug” and got the message:
Identifying platform…
Platform found: debug/linux/4.10/64/x86/gcc/6.3/default
Error running unit test executable for protocols.test – not all tests may be availible.
Error running unit test executable for core.test – not all tests may be availible.
Error running unit test executable for basic.test – not all tests may be availible.
Error running unit test executable for numeric.test – not all tests may be availible.
Error running unit test executable for utility.test – not all tests may be availible.
Error running unit test executable for apps.test – not all tests may be availible.
Unit test summary
Total number of tests: 0
number tests passed: 0
number tests failed: 0
Success rate: 0%
End of Unit test summaryDone!
14) Restarted Terminal, then typed “cd ./Desktop/Rosetta/main/source/build/test/debug/linux/4.10/64/x86/gcc/6.3/default”
15) In Terminal, typed “./core.test ScoreFunctionTest –database /Desktop/Rosetta/main” and got the message “./core.test: error while loading shared libraries: libsqlite3.so: cannot open shared object file: No such file or directory”
So, what’s going on??? Thanks so much for your help!!! I know this is getting a bit involved, but any advice you might have is much appreciated.
-
October 28, 2017 at 8:55 pm #13837Anonymous
Hmm…. I really don’t know why the automatic path discovery feature isn’t working for you.
At this point the only recommendations I have for you would be to add the path to the appropriate libsqlite3.so file (either debug or release) to your LD_LIBRARY_PATH environment variable prior to running any Rosetta runs.
-
November 17, 2017 at 4:19 am #13886Anonymous
Hi rmoretti,
I’m on Ubuntu 17.10. I did the following and it worked:
In Terminal, typed “export LD_LIBRARY_PATH=~/Desktop/Rosetta/main/source/build/external/release/linux/4.13/64/x86/gcc/7/default/:$LD_LIBRARY_PATH” (the extra “:$LD_LIBRARY_PATH” at the end apparently appends the path to whatever other paths are already set, without overwriting them. This extra bit is crucial, and nothing worked without this extra piece.)
In Terminal, typed “printenv | grep LD_LIBRARY_PATH” to confirm that the variable was set, pressed Enter and got the output “LD_LIBRARY_PATH=/home/ajvincelli/Desktop/Rosetta/main/source/build/external/release/linux/4.13/64/x86/gcc/7/default/:” (a good sign)
In Terminal, typed “cd ./Desktop/Rosetta/main/source/build/test/debug/linux/4.13/64/x86/gcc/7/default” and pressed Enter, then typed “./core.test ScoreFunctionTest –database ~/Desktop/Rosetta/main/database” and pressed Enter, and it ran!
In Terminal, typed “cd ~” and pressed Enter (because my Terminal wasn’t letting me navigate directly for some reason), then typed “cd ./Desktop/Rosetta/main/source” and pressed Enter, then typed “python test/run.py –mode=debug” and pressed Enter and it worked! Hooray! (However, “python test/run.py” still doesn’t work for some reason.)
I feel like this whole problem is related to newer versions of Ubuntu. See the “File-location related variables” section of this website: https://help.ubuntu.com/community/EnvironmentVariables
On that website it says “Since Ubuntu 9.04 Jaunty Jackalope, LD_LIBRARY_PATH cannot be set in $HOME/.profile, /etc/profile, nor /etc/environment files.” Maybe that’s how Rosetta is trying to set the variable? And that method is no longer supported? Just a thought.
I also tried to permanently set the path by adding a conf file to my ld.so.conf.d folder, but that didn’t work. Darn. I guess I will just run the above code to manually set the path in every new Terminal session before running any Rosetta code.
Thanks so much for your help!!
-
-
September 26, 2017 at 2:34 am #13789Anonymous
I also get an error, after following the instructions at https://www.rosettacommons.org/docs/latest/development_documentation/test/run-unit-test. I compiled the Rosetta libraries in debug mode, (scons.py -j 2 mode=debug), then did the test compile (scons.py -j 2 mode=debug cat=test). They compiled without errors. When I ran the test code (python test/run.py), I get the same errors as destrudo. The directory tree is complete, as rmoretti asked (main/source/build/src/debug/linux/4.10/64/x86/gcc/6.3/default). Any ideas? Thanks!
-
March 29, 2021 at 3:52 am #15820Anonymous
It’s been a few years since my last post here, but I just learned something new. If you update your Ubuntu OS, and/or your GCC version gets updated, and then you re-compile Rosetta, that magic `export LD_LIBRARY_PATH` command that I mentioned above won’t work anymore. The filepath in the Rosetta folder changes! You may get the error “libsqlite3.so: cannot open shared object file: No such file or directory”, or the more cryptic “ZN9CifString12UnknownValueE”. If this happens to you, check the path and update the command as necessary (for me on Ubuntu 20.04, the updated magic command is `export LD_LIBRARY_PATH=~/Desktop/Rosetta/main/source/build/external/release/linux/5.4/64/x86/gcc/9/default/:$LD_LIBRARY_PATH`). Hope this helps others!
-
-
AuthorPosts
- You must be logged in to reply to this topic.