Windows 7 64 bit OS using Cygwin build error?

[Anonymous]

Hi all, new poster, new to Rosetta.

I’ve been trying to get Rosetta to run on a Windows 7 64 bit OS using Cygwin. I thought I had finally made progress when I got the build to successfully complete (my Bin and Build directories were populated, as expected), but whenever I try to run any program from my Bin folder (I’m focusing on docking programs), it gives me an error:

“error while loading shared libraries: protocols.dll: cannot open shared object file: No such file or directory”

And I can’t figure out why it can’t find the protocols.dll. It is deep in the build/src… as expected. When I try to run from the build/src/release/cygwin/1.7/32/x86/gcc directory, it gives me the error:

“error while loading shared libraries: ?: cannot open shared object file: No such file or directory”

I haven’t found any information about this error online. I’ve re-built it twice (deleted everything and re-scons’d) with no success. Any thoughts?

Thanks!

[Anonymous]

Beyond telling you that you’ve tried all the right things, there’s nothing I know to do. It appears to be failing due to the linker step, which may help you google for better results. It’s not failing during linking (that’s part of compiling), but whatever the linker does, it’s doing it wrong, which is why the executables won’t run.

Is it possible that your files are compiled in one location and then moved to another? Is it possible that the underlying file system does something strange such that the file paths to the libraries are being corrupted somehow? Try doing everything from the simplest paths possible to see if it removes the error.

[Anonymous]

Hi smlewis, thanks for the response!

Using cygcheck, I figured out that it was not finding any of the dll’s deep in /build/../../.. As a work-around (since I can’t figure out how to tell Cygwin to look in a directory for dll’s…), I copied them over to a folder where it would see them (inside Cygwin). This brought me to the next error. I did:

./rosetta_source/bin/docking_protocol.cygwingccrelease -database /rosetta_database @options

After a couple minutes:

ERROR: Option matching -database not found in command line top-level context

Next, I tried:

./rosetta_source/bin/docking_protocol.cygwingccrelease -help

And at least this came back with, I assume, the normal menu. (Usage, Options, etc)

I saw a similar problem at http://www.rosettacommons.org/content/error-option-matching-s-not-found-command-line-top-level-context but didn’t see any resolutions. I tried renaming the “z.lib” as suggested at the end of that thread. No luck, same error. I’m guessing I’m now running into the same problem they were.

I’m not much of a programmer (at all) and I know you all don’t work with Cygwin. I appreciate any thoughts! (:

[Anonymous]

Yeah, you’re right, we’ve seen the cygwin windows build reject options before. We can’t reproduce it so it’s hard to fix.

The fact that it accepts -help and rejects -database says something, but I don’t know what. -help is hard-coded into the options reader; all the other options live in big files in src/basic/options. Maybe something is getting skipped in the cygwin build such that the option system isn’t ever initialized.

How long is the list of options you get from help (approximately)? (if cygwin has wc, then just do rosetta -help | wc -l). It should be something like 3500-4000 lines. If it’s only a few lines that may be useful to know.

“I’m not much of a programmer (at all)” -> You’ve already displayed more knowledge of compiler theory than most people who have compiler problems. Don’t sweat it. (Do, however, seriously consider installing an Ubuntu partition or VM; you appear to have the skills and it will probably run Rosetta better. Also consider that Rosetta isn’t written for desktops anyway…)

[Anonymous]

Do not try to build Cygwin build with shared libs (DLL’s) – it will not work as expected. (I will not go in to much details here but basically you need to make one DLL instead of current five or all singleton code will got broken).

Solution to your problem would be to use static build which does not have this problem (./scons.py mode=release extras=static)

Also, if you care to have native window build we going to release PyRosetta native build for windows shortly.

[Anonymous]

Sorry for the slow response. Took some time to get through the suggestions! (:

From Bin directory:
./docking_protocol.cygwingccrelease -help | wc -l
18

Only 18 lines when there are supposed to be 3500-4000?

I tried removing everything and re-building using a static build, as Sergey suggested:
scons mode=release extras=static

Looked like it was building correctly, then ran into an error pretty quickly where it could not find “core1” in src.

I again removed everything and re-built using:
scons bin mode=release extras=static

This took a lot longer than previous builds. Before, it took ~2.5 hours to build. This time was at least 7 hours (I had to leave before it was finished). During the build, it repeatedly reported “… duplicate section … has different size”. I read somewhere that this has to do with a warning in cygwin related to very large files. I also noticed that processes created by cygwin (I’m assuming) were frequently going over 1gb in memory. Regardless, it eventually completed with no errors.

I repeated the help lines count. Reported 3588 this time.

Next, I ran:
./docking_protocol.cygwingccrelease -database /cygdrive/c/rosetta/rosetta_database

This seemed to finally find the database! It opened a number of database files (10-20 or so). Then it ran into a new problem. The last few lines:

protocols.docking.DockingProtocol: Setting docking foldtree
protocols.docking.DockingProtocol: old fold tree: FOLD_TREE
protocols.docking.DockingProtocol:
ERROR: cutpoint
ERROR:: Exit from: src/protocols/docking/util.cc line: 90

I looked up line 90 in util.cc:
89: // calculate jump points from partners
90: runtime_assert( cutpoint );
91: runtime_assert( movable_jumps.size() > 0 );

I’ve also tried:
./docking_protocol.cygwingccrelease -database /cygdrive/c/rosetta/rosetta_database @options
ERROR: Option file open failed for: options

So I’m at a new impasse. I haven’t thoroughly scoured the web yet about these errors, so perhaps I’m missing something obvious. Thanks again!

[Anonymous]

Ah, that’s good news! I figured I’d get some kind of “no input” error, and I was still having compiling problems. Obviously still very new to Rosetta.

I did not have an options file named “options” in that directory. That mystery is solved!

Next, I tried running the example docking demo in rosetta_demos (1brs.pdb).
./bin/docking_protocol.cygwingccrelease @flags -database /cygdrive/c/rosetta/rosetta_database

Had trouble with flag file input:
-dock_mcm

Found previous forum post said this was no longer necessary, removed that line from the flags file, ran the same command:
./bin/docking_protocol.cygwingccrelease @flags -database /cygdrive/c/rosetta/rosetta_database

With the modified flags file (originally copied from the rosetta_demos folder):
-s input/1brs.pdb
-dock_pert 3 8
-spin
-mute core.util.prof ## dont show timing info
-randomize1
-out:file:fullatom
-out:file:o 1brs.test

Seemed to be working! But then I couldn’t find any of the ouputs listed in the flags file (fullatom?, 1brs.test?) when it finished. The last few lines were:

protocols.jd2.FileSystemJobDistrubutor: Too many retries (max_retry_job = 10)
protocols.jd2.JobDistributor: 1brs_0001 reported failure and will retry
protocols.jd2.JobDistributor: no more batches to process…
protocols.jd2.JobDistributor: 1 jobs considered, 11 jobs attempted in 153 seconds

I tried running with a pdb I had previously prepared for a docking test and got the same error.

Seems like I’m running into pretty basic errors now. Probably more reading would solve these, but I’ll keep you updated anyway for now. Maybe this will help others run who into the same problems? Thanks again!

[Anonymous]

I asked Sergey elsewhere why:

“If I recall correctly the problem was that for some reason all singletons was initialized a multiple times. So the solution was either build a single shared lib instead of many or go with static lib. I think roots of this problem is in how DLL works.”

We are attempting to tweak the SCons settings so that cygwin builds forcibly use static linking instead of dynamic so you won’t have this problem in the future.

[Anonymous]

Great; we are past compiling errors and in to actual Rosetta errors! 7 hours sounds high for a static build, but not too unreasonable given cygwin, etc. (A one-threaded static build is many hours on my own machine).

I don’t have quite enough information yet to diagnose your current errors. This commandline: “./docking_protocol.cygwingccrelease -database /cygdrive/c/rosetta/rosetta_database” will fail because there is no input structure (the cutpoint error is where it fails for me too).

Your next command line fails because “options” is not found. This begs the question: do you have an options file, named options, in that directory…? If so, I would guess cygwin is botching the @ symbol somehow (I’m not clear on how it works anyway); try putting all the options directly on command line. If not, well, try making an options file and put it there. The docking documentation will tell you what options do what; at the very least you’ll need -s or -l to pass in input structures.

[Anonymous]

protocols.jd2.FileSystemJobDistrubutor: Too many retries (max_retry_job = 10)

You aren’t getting any output because filters are failing. Docking filters internally; if it thinks a trajectory is going to produce a garbage structure, it gives up and retries. If these are the demo examples, running with demo flags, which is what I think you are doing, then they should not be failing the filters. If you changed the flags or are using your own inputs, then filter failure is likely legitimate and means Rosetta thinks the two things won’t dock; you can try relaxing the filters (I don’t know how; the documentation probably will).

[Anonymous]

That is correct. Initially, I ran with demo flags (except that -dock_mcm was removed due to a previously reported error) and demo input (1brs.pdb). Second try was with the same flags and my own input. Both gave the same error.

[Author]

Posts