Member Site › Forums › Rosetta 3 › Rosetta 3 – General › SCons compilation error (Windows XP, 32bit)
- This topic has 28 replies, 5 voices, and was last updated 14 years, 5 months ago by
Anonymous.
-
AuthorPosts
-
-
August 3, 2009 at 7:57 am #540
Anonymous
Unfortunately I can’t manage to compile Rosetta 3.0 on a windows platform
(see command line output below).Python, run from cygwin shell or the command line, throws an KeyError:
“raise KeyError, “Processor architecture ‘%s’ is unsupported.” % (actual)
KeyError: “Processor architecture ‘x86 Family 6 Model 15 Stepping 13,
GenuineIntel’ is unsupported.”I tried different machines (Intel Core2Duo | AMD Athlon 64 | Intel Pentium),
but the error is still the same…Could anyone please help?
Regards
Christian================================== Software ===================================
Windows XP, Version 5.1 (Build 2600.xpsp_sp3_gdr.090206-1234:
Service Pack 3) – 32bitPython 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32SCons by Steven Knight et al.: engine: v1.2.0.r3842, 2008/12/20 22:59:52,
by scons on scons-devMinGW Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure –with-gcc –with-gnu-
ld –with-gnu-as –host=mingw32 –target=mingw32 –prefix=/mingw –enable-
threads –disable-nls –enable-languages=c,c++,f77,ada,objc,java –disable-
win32-registry –disable-shared –enable-sjlj-exceptions –enable-libgcj
–disable-java-awt –without-x –enable-java-gc=boehm –disable-libgcj-
debug –enable-interpreter –enable-hash-synchronization –enable-
libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
======================================================================================================== Command line output ================================
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.C:rosetta3rosetta3_source>scons bin mode=release
scons: Reading SConscript files …scons: warning: The Options class is deprecated; use the Variables class
instead
.
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 40, in
setup_build
_optionsscons: warning: The EnumOption() function is deprecated; use the
EnumVariable()
function instead.
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 48, in
setup_build
_optionsscons: warning: The ListOption() function is deprecated; use the
ListVariable()
function instead.
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 56, in
setup_build
_options
Traceback (most recent call last):
File “C:rosetta3rosetta3_sourceSConstruct”, line 137, in main
build = SConscript(“tools/build/setup.py”)
File
“C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”,
lin
e 612, in __call__
return apply(method, args, kw)
File
“C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”,
lin
e 549, in SConscript
return apply(_SConscript, [self.fs,] + files, subst_kw)
File
“C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”,
lin
e 259, in _SConscript
exec _file_ in call_stack[-1].globals
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 405, in
build = setup()
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 396, in setup
build.options_requested, build.options = setup_build_options()
File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 113, in
setup_bu
ild_options
supported, actual.os, requested.arch
File “C:rosetta3rosetta3_sourcetoolsbuildsetup_platforms.py”, line
182, i
n select_arch
raise KeyError, “Processor architecture ‘%s’ is unsupported.” % (actual)
KeyError: “Processor architecture ‘x86 Family 6 Model 15 Stepping 13,
GenuineInt
el’ is unsupported.”
scons: done reading SConscript files.
scons: Building targets …
scons: `bin’ is up to date.
scons: done building targets.C:rosetta3rosetta3_source>
======================================================================
-
August 6, 2009 at 6:14 am #4129
__push__
(:sad:)
-
August 7, 2009 at 10:40 pm #4133
disclaimer: i don’t and never have compiled on windows.
The problem is that SCons does not recognize your compiler architecture. This is not strictly speaking a problem with Rosetta, but rather the SCons configuration files.
Look for the file /tools/build/user.settings. It contains directions for SCons when building. You need to get it to look something like this:
> settings = {
> “user” : {
> “prepends” : {
> },
> “appends” : {
> “flags”:{ “compile”:[“march=i686”] },
> },
> “overrides” : {
> },
> “removes” : {
> “flags”:{“compile”:[“march=pentium4″,”march=athlon”] },
> },
> }
> }Where “march=i686” is a fairly generic compiler architecture. I don’t know what you need on the remove line, but you need it to remove whatever the architecture it’s not finding is (not necessarily pentium4 or athlon). You might need to put the “flags”:{“compile”:[march=i686″]} line on the overrides group instead.
You should also try the SCons documentation if this doesn’t help.
-
August 7, 2009 at 10:55 pm #4137
unsurprisingly, this forum has ruined the python code. Put an endline character where there are > and it should look right. The gist of it came through?
-
August 10, 2009 at 7:08 am #4142
Thanks for your hint, smlewis.
I will try to fix that today and post the solution here.
-
August 18, 2009 at 8:38 pm #4154
I am running Rosetta3 on Mandrake Linux through a VMWare virtual machine running on top of Windows XP 23-bit, and I had the exact same problem. Here is how I fixed it:
Open tools/build/setup_platforms.py and go to the line with the that holds the “actual” variable array (I think it is 156). Add the follwing string to it as such:
(code)
actual = {
# Results from platform.processor()
“i386”: “x86”,
…
“Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz” : “x86”,
“x86 Family 6 Model 15 Stepping 13, GenuineIntel” : “x86”, -
August 18, 2009 at 8:38 pm #4155
Sorry, the post keeps getting cut off. If it doesn’t make sense, let me know.
-Brett -
September 1, 2009 at 2:18 pm #4166
Thanks alot “smlewis” and Brett for your replies!
Scons is now running – but no executable files are created during compilation run…
Any ideas?
(:redface:)
-
September 2, 2009 at 2:02 pm #4172
What is in the bin folder?
What is in the build folder?
Does it compile anything at all?
Did you remember the “bin” flag on the command line (bin = binaries = executables)? Without bin it does just the libraries.
-
September 3, 2009 at 12:28 pm #4173
Hi smlewis,
I think I used the “bin” flag on the command line with SCons (see output below).
The binary folder contains many *.linuxgccrelease with 0 bytes in size –
as far as I can tell, they are the identical to the ones of the installer archive.In the build folder, there are many *.o and *.os files. No executables as far as I can tell.
Can you tell me – probably from the output – where sth went wrong while compiling?
Cheers
============================= SCons output =============================
C:rosetta3_Bundlesrosetta3_source.tarrosetta3_source>scons bin mode=release
scons: Reading SConscript files …scons: warning: The Options class is deprecated; use the Variables class instead
.
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetup.
py”, line 40, in setup_build_optionsscons: warning: The EnumOption() function is deprecated; use the EnumVariable()
function instead.
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetup.
py”, line 48, in setup_build_optionsscons: warning: The ListOption() function is deprecated; use the ListVariable()
function instead.
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetup.
py”, line 56, in setup_build_options
Traceback (most recent call last):
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourceSConstruct”, lin
e 137, in main
build = SConscript(“tools/build/setup.py”)
File “C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”, lin
e 612, in __call__
return apply(method, args, kw)
File “C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”, lin
e 549, in SConscript
return apply(_SConscript, [self.fs,] + files, subst_kw)
File “C:pythonLibsite-packagesscons-1.2.0SConsScriptSConscript.py”, lin
e 259, in _SConscript
exec _file_ in call_stack[-1].globals
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetu
p.py”, line 405, in
build = setup()
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetu
p.py”, line 398, in setup
build.environment = setup_environment(build.settings)
File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetu
p.py”, line 348, in setup_environment
env[“ENV”][key] += value
TypeError: coercing to Unicode: need string or buffer, list found
scons: done reading SConscript files.
scons: Building targets …
scons: `bin’ is up to date.
scons: done building targets.C:rosetta3_Bundlesrosetta3_source.tarrosetta3_source>
============================= End output =============================
-
September 3, 2009 at 12:30 pm #4174
The output text formatting is a mess …
sorry for that!(:confused:)
-
September 4, 2009 at 2:17 pm #4176
“scons: `bin’ is up to date. scons: done building targets. ” This is supposed to mean you’re done!
The 0 byte things in the bin folder are symbolic links to the executeables – do they not work when you try to run them? When you say “installer archive”, do you mean that they were already there when you unpackaged the code and have not been changed?
The fact that your bin folder says linuxgccrelease (when you’re on a windows box) and the fact that there are ONLY o and os files in your build folder implies that the executeable step isn’t occuring, even though the library files are getting built. Are there any large .so files (libcore.so, libprotocols.so, etc)? These are the library files. If those files are missing, then it might be a problem with the linker – it’s not used until the last steps when executeables and libraries are combined.
The error scons is throwing (and i’m not a scons expert) implies that there’s something misformatted in the build settings – I’d guess when we tried to fix your pilot apps file earlier, the formatting got corrupted. You can try reading the build files directly into the python interpreter to check if they’re properly formatted: I introduced a deliberate error into my user.settings, and python alone notices it without scons.
Go to tools/build, and run “python user.settings” and see if it complains. If it does not complain, deliberately add some garbage to the file (delete a bracket or comma) and try again as a positive control. If it does complain, try to fix the formatting error.
-
September 7, 2009 at 8:10 am #4178
Hi,
the symbolic links don’t seem to work for windos (btw: running xp non-virtually). When I try to run them with the command line, XP’s “file open with” dialogue appears.
They seem be be unchanged compared to the ones from unpacking the source code (“installer archive”).Some large .so files (and the mentioned ones above) are present in the folder __buildsrcreleaselinux2.632x86gcc__ only.
The __user.settings.py__ as well as the __setup_platforms.py__ run fine – without any complaint. By removing some brackets, I can generate an error message.
Could I somehow force SCons to build windows executables?
-
September 7, 2009 at 3:06 pm #4180
If it got as far as the large .so files, then the linker is fine – it’s just failing to build executeables.
Have you modified src/apps.src.settings? If it was empty, then you’d get this behavior.
-
September 10, 2009 at 8:05 am #4184
Nope, I haven’t touched that file –
only the __setup_platforms.py__ (platform not recognized problem).Everything else is out-of-the-box.
-
September 10, 2009 at 3:57 pm #4185
Christian-
Would you tell me which svn revision of mini you’re compiling, which version of MinGW you’re using, and how you generated the “MinGW generating specs from…” output in your original post? I’d like to get MinGW working, partly to look into your non-linking issue, but I’m running into MinGW issues which you seem to have avoided.
Also, if you’re up for setting up cygwin, I’m working on instructions for compiling using cygwin instead. I know it’s possible, since I’ve done it; I just need to recreate the steps
-
September 11, 2009 at 8:47 am #4186
Hi crispy,
for the “MinGW generating specs from..” output, I used the “-v” (which stands for “–version”) parameter with the C++ compiler executable:
__mingw32-c++.exe -v__
If the __/MinGW/bin/__ folder is added to the system’s ===$PATH=== variable, you can simply run the command in a text console from anywhere.
Unfortunately, I don’t fully understand your question regarding the “svn revision of mini you’re compiling”. As far as I can tell, the abbreviation “SVN” stands for SubVersion … And the revision is a compiling version number. But: What is mini? Ever tried to google that word only? (:wink:)
I’m going to give cygwin a try and install it this week: If it works, I will send you my notes on the steps necessary to reproduce.
-
September 14, 2009 at 4:15 pm #4189
Right – thought I tried that with MinGW, but obviously not
“mini” is the name most of the developers use for the Rosetta 3.x code. And looking more closely at your output from the first post, it looks like you’re using release 3.0, which answers my question. Generally I’m working with one of the later releases from the subversion repository, which is why I assumed you were.
I’m wondering why your executables end in “.linuxgccrelease”. I’m also curious as to why you didn’t get the errors I did when I tried to use MinGW: on my machine, it was unable to find some of the basic typedefs, and couldn’t compile anything; I had to hack some things to get past that, and even then haven’t gotten it to compile with MinGW yet.
Two questions: First, when you compile, where do your object and executable files end up? This will be somewhere in the rosetta3_source/build directory; you can either examine that directory, or look at your scons output. For example, on my linux box, I get this line for the “relax” executable, which shows it being placed in “build/src/release/linux/2.6/32/x86/gcc/static”: __g++ -o build/src/release/linux/2.6/32/x86/gcc/static/relax.linuxgccrelease -static build/src/release/linux/2.6/32/x86/gcc/static/apps/public/relax.o -Llib -Lexternal/lib -Lbuild/src/release/linux/2.6/32/x86/gcc/static -Lsrc -L/usr/local/lib -L/usr/lib -lprotocols -lcore -lnumeric -lutility -lObjexxFCL -lz__
Second, when the links are made, where does it try to link to? On my linux box, this scons output line gives the answer: __Install file: “build/src/release/linux/2.6/32/x86/gcc/static/relax.linuxgccrelease” as “bin/relax.linuxgccrelease”__ I’m guessing that your MinGW build is trying to link somewhere other than where your compiled code is.
-
-
October 1, 2009 at 9:58 am #4206
Hi Crispy,
unfortunately, I have been very busy with some other work… but meanwhile managed to go at least half-way through compiling with cygwin.
Using cygwin, compiling of python/mingw/scons (stable/latest) with the shipped gcc (3.4.4) didn’t work at all to solve the problem.
Instead, I installed cygwin with all features – including python (2.5.2) and ran the local scons-local script from Rosetta’s external subfolder.
Unlike the many tries before, my CPU now is busy for quite a while and SCons gives me some messages about its current compilation status:^scons: Reading SConscript files …
Copy(“user.options”, “user.options.template”)
Copy(“user.settings”, “user.settings.template”)
Copy(“/home/user/rosetta_source/src/pilot_apps.src.settings”, “/home/user/rosetta_source/src/pilot_apps.src.settings.template”)
scons: done reading SConscript files.
scons: Building targets …
g++ -o build/src/release/cygwin/1.5/32/x86/gcc/apps/public/AbinitioRelax.o -c -pipe -ffor-scope -W -Wall -pedantic -Wno-long-long -malign-double -march=pentium4 -O3 -ffast-math -funroll-loops -finline-functions -finline-limit=20000 -s -Wno-unused-variable -DNDEBUG -Isrc -Iexternal/include -Isrc/platform/cygwin/32/gcc -Isrc/platform/cygwin/32 -Isrc/platform/cygwin -Iexternal/boost_1_38_0 -I/usr/local/include -I/usr/include src/apps/public/AbinitioRelax.cc
”… very many entries here similar to the one above …”
g++ -o build/src/release/cygwin/1.5/32/x86/gcc/utility.dll -lz -Xlinker –enable-auto-import -shared build/src/release/cygwin/1.5/32/x86/gcc/utility/basic_sys_util.os build/src/release/cygwin/1.5/32/x86/gcc/utility/string_util.os build/src/release/cygwin/1.5/32/x86/gcc/utility/heap.os build/src/release/cygwin/1.5/32/x86/gcc/utility/exit.os build/src/release/cygwin/1.5/32/x86/gcc/utility/LexicographicalIterator.os build/src/release/cygwin/1.5/32/x86/gcc/utility/file/file_sys_util.os build/src/release/cygwin/1.5/32/x86/gcc/utility/file/FileName.os build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os build/src/release/cygwin/1.5/32/x86/gcc/utility/file/PathName.os build/src/release/cygwin/1.5/32/x86/gcc/utility/boinc/boinc_util.os build/src/release/cygwin/1.5/32/x86/gcc/utility/Tag/Tag.os build/src/release/cygwin/1.5/32/x86/gcc/utility/options/keys/OptionKeys.os build/src/release/cygwin/1.5/32/x86/gcc/utility/io/icstream.os build/src/release/cygwin/1.5/32/x86/gcc/utility/io/izstream.os build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ocstream.os build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os build/src/release/cygwin/1.5/32/x86/gcc/utility/excn/Exceptions.os build/src/release/cygwin/1.5/32/x86/gcc/utility/pointer/ReferenceCount.os build/src/release/cygwin/1.5/32/x86/gcc/utility/pointer/ReferenceCountMI_.os build/src/release/cygwin/1.5/32/x86/gcc/utility/options/OptionCollection.os build/src/release/cygwin/1.5/32/x86/gcc/utility/options/mpi_stderr.os -Llib -Lexternal/lib -Lbuild/src/release/cygwin/1.5/32/x86/gcc -Lsrc -Lbuild/src/release/cygwin/1.5/32/x86/gcc/lib/cygwin -Lsrc/lib/cygwin -L/usr/local/lib -L/usr/lib -lObjexxFCL -lz
scons: building terminated because of errors.^
The error log ends with the following lines:
^”… frequent “might be used uninitialized in this function” errors (see below) here …”/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warni
ng: ‘__cur’ might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warni
ng: ‘__cur’ might be used uninitialized in this function”… last entries from the log …”
build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEE11res
et_stateEv[zlib_stream::basic_zip_streambuf::reset_state()]+0
x34): undefined reference to `_deflateReset’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEED1E
v[zlib_stream::basic_unzip_streambuf::~basic_unzip_streambuf(
)]+0x55): undefined reference to `_inflateEnd’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEED0E
v[zlib_stream::basic_unzip_streambuf::~basic_unzip_streambuf(
)]+0x55): undefined reference to `_inflateEnd’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEE5flus
hEi[zlib_stream::basic_zip_streambuf::flush(int)]+0x47): unde
fined reference to `_crc32′build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEE5flus
hEi[zlib_stream::basic_zip_streambuf::flush(int)]+0x69): unde
fined reference to `_deflate’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEEC1E
RSijjj[zlib_stream::basic_unzip_streambuf::basic_unzip_stream
buf(std::basic_istream&, unsigned int, unsigned i
nt, unsigned int)]+0x1c0): undefined reference to `_inflateInit2_’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEE17u
nzip_from_streamEPci[zlib_stream::basic_unzip_streambuf::unzi
p_from_stream(char*, int)]+0x2e): undefined reference to `_inflate’build/src/release/cygwin/1.5/32/x86/gcc/utility/file/gzip_util.os:gzip_util.cc:(
.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEE17u
nzip_from_streamEPci[zlib_stream::basic_unzip_streambuf::unzi
p_from_stream(char*, int)]+0x84): undefined reference to `_crc32′build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os:ozstream.cc:(.tex
t$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEED1Ev[zlib
_stream::basic_zip_streambuf::~basic_zip_streambuf()]+0x6e):
undefined reference to `_deflateEnd’build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os:ozstream.cc:(.tex
t$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEED0Ev[zlib
_stream::basic_zip_streambuf::~basic_zip_streambuf()]+0x6e):
undefined reference to `_deflateEnd’build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os:ozstream.cc:(.tex
t$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEEC1ERSojNS
_9EStrategyEjjj[zlib_stream::basic_zip_streambuf::basic_zip_s
treambuf(std::basic_ostream&, unsigned int, zlib_
stream::EStrategy, unsigned int, unsigned int, unsigned int)]+0x262): undefined
reference to `_deflateInit2_’build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os:ozstream.cc:(.tex
t$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEE13zip_to_
streamEPci[zlib_stream::basic_zip_streambuf::zip_to_stream(ch
ar*, int)]+0x3e): undefined reference to `_crc32′build/src/release/cygwin/1.5/32/x86/gcc/utility/io/ozstream.os:ozstream.cc:(.tex
t$_ZN11zlib_stream19basic_zip_streambufIcSt11char_traitsIcESaIcEhSaIhEE13zip_to_
streamEPci[zlib_stream::basic_zip_streambuf::zip_to_stream(ch
ar*, int)]+0x5e): undefined reference to `_deflate’collect2: ld returned 1 exit status
scons: *** [build/src/release/cygwin/1.5/32/x86/gcc/utility.dll] Error 1^
Back to your questions:
First, the object files now end up in sub-folders of the following address:
__C:cygwinhomeuserrosetta_sourcebuildsrcreleasecygwin1.532x86gcc__
This should be correct.
Second, as far as I can tell, no actual executables (*.exe) or links to those are created – the __bin__ folder is empty.
Cheers
Christian -
October 1, 2009 at 1:39 pm #4208
These are linker errors trying to link against zlib. zlib is a external compression library rosetta uses to allow gzip compressed IO.
There should be a file external/lib/z.lib. You could try replacing it with a windows DLL from the zlib site? I haven’t a clue if that will work (hopefully crispy will). http://www.zlib.net/
-
October 2, 2009 at 2:34 pm #4216
Rename external/lib/z.lib to something else. I ran into the same problem with Cygwin: for some reason, this zlib is included and is part of the library path. But it doesn’t work with Cygwin. Renaming it allows gcc in Cygwin to find and link against the correct zlib.
Sorry if this is a duplicate; I’m not seeing my posts show up.
-
-
October 2, 2009 at 11:11 am #4210
I will try that ASAP.
Thank you for your help
(:razz:)
and have a nice weekend-
October 2, 2009 at 2:27 pm #4213
Try renaming external/lib/z.lib to something else. I ran into the same problem with Cygwin: for some reason, this zlib is included and is part of the library path. But it doesn’t work with Cygwin. Renaming it allows gcc in Cygwin to find and link against the correct zlib.
BTW, the only reason I know this is that I happened to be sitting next to Sergey at RosettaCon when this error came up
-
-
October 2, 2009 at 2:28 pm #4214
Try renaming external/lib/z.lib to something else. I ran into the same problem with Cygwin: for some reason, this zlib is included and is part of the library path. But it doesn’t work with Cygwin. Renaming it allows gcc in Cygwin to find and link against the correct zlib.
BTW, the only reason I know this is that I happened to be sitting next to Sergey at RosettaCon? when this error came up
-
October 2, 2009 at 2:33 pm #4215
Sorry for the duplicate posts; I swear the “next page” link wasn’t there before… (:eek:)
-
October 7, 2009 at 9:18 am #4220
(:biggrin:) I wouldn’t even have noticed, if you hadn’t told me!
Current status: After having removed/renamed __external/lib/z.lib__ the compilation process runs to a certain point (I guess pretty much one of the last steps), where another error occurs:
^/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warning: ‘__cur’ might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warning: ‘__cur’ might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h: In member function `void std:vector:_M_fill_insert(_gnu_cxx:_normal_iterator, size_t, const _Tp&)
[with _Tp = utility:options:RealOption, _Alloc = std:allocator]’:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warning: ‘__cur’ might be used uninitialized in this function
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_uninitialized.h:82: warning: ‘__cur’ might be used uninitialized in this function/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../__i686-pc-cygwin/bin/ld: out of memory__ allocating 20 bytes after a total of 1603076096 bytes
collect2: ld returned 1 exit statusscons: *** [build/src/release/cygwin/1.5/32/x86/gcc/protocols.dll] Error 1
scons: building terminated because of errors.^
Although running a x86 system with 1GB RAM here at work, the peak memory usage of approx. 1.7 GB RAM should be okay (0.7 RAM addressed as swap).
At home I tried the same thing with 4 GB RAM installed (3.2 GB available) and got the same error.The only documentation of this “feature” seems to be a bug report from 2002 regarding “GNU Linker”:
[http://www.mail-archive.com/cygwin@cygwin.com/msg12681.html|Re: ld crash]
Any workaround possible?
-
October 7, 2009 at 2:58 pm #4221
Are you compiling with mode=release? The debug build takes a ton of memory (it’s a known issue we’re working on).
If you know which executeables you need, you might be able to get away with slicing away large chunks of code. There is unfortunately a lot of lateral dependency in the protocols library, which makes it harder.
You can “turn off” chunks of compiling by commenting out lines in the file apps.src.settings and protocols.src.settings. It won’t hurt to just try turning things off and on. Don’t touch the moves or jobdist (or jd2) directories, but many of the other ones are fair game. For example if you want to do docking, you can probably turn off the rna, dna, and abinitio folders. If you let me know which executeables you need I can attempt to tell you what you can safely excise.
If you do decide to try this, if you turn something off you shouldn’t, it will manifest as linker errors where certain functions cannot be found. That tells you that something is no longer compiling that’s necessary for some reason.
-
October 20, 2009 at 12:06 pm #4238
Seems to be working now… (:mrgreen:)
Here is what I did:
1. Installed cygwin (full package)
2. __cd__’ed into __/rosetta_source/__
2. Renamed __/rosetta_source/external/lib/z.lib__ to __/z.lib.donotuse__
3. Command is __python external/scons-local/scons.py bin mode=release extras=static__
Software versions:
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
SCons by Steven Knight et al.:
script: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkok
engine: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkokPython 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
Cheers
-
July 23, 2010 at 5:14 am #4498
Hello..I’m new to cygwin, python, and scons, and I have been trying to compile the rosetta3.1 and I’ve got the following error:
marsia@lembayung-vaio ~/rosetta_source
$ /home/marsia/rosetta_source/external/scons-local/scons.py bin mode=release
scons: Reading SConscript files …
/home/marsia/rosetta_source/external/scons-local/scons-local-0.98.5/SCons/Platform/posix.py:38: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module.
import popen2
/home/marsia/rosetta_source/external/scons-local/scons-local-0.98.5/SCons/Tool/msvs.py:37: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import md5
Traceback (most recent call last):
File “/home/marsia/rosetta_source/SConstruct”, line 137, in main
build = SConscript(“tools/build/setup.py”)
File “/home/marsia/rosetta_source/external/scons-local/scons-local-0.98.5/SCons/Script/SConscript.py”, line 596, in __call__
return apply(method, args, kw)
File “/home/marsia/rosetta_source/external/scons-local/scons-local-0.98.5/SCons/Script/SConscript.py”, line 533, in SConscript
return apply(_SConscript, [self.fs,] + files, subst_kw)
File “/home/marsia/rosetta_source/external/scons-local/scons-local-0.98.5/SCons/Script/SConscript.py”, line 256, in _SConscript
exec _file_ in call_stack[-1].globals
File “/home/marsia/rosetta_source/tools/build/setup.py”, line 410, in
build = setup()
File “/home/marsia/rosetta_source/tools/build/setup.py”, line 401, in setup
build.options_requested, build.options = setup_build_options()
File “/home/marsia/rosetta_source/tools/build/setup.py”, line 112, in setup_build_options
actual.os = setup_platforms.select_os(supported, requested.os)
File “/home/marsia/rosetta_source/tools/build/setup_platforms.py”, line 125, in select_os
raise KeyError, “Operating system ‘%s’ is unsupported.” % (actual)
KeyError: “Operating system ‘cygwin_nt-6.0’ is unsupported.”
scons: done reading SConscript files.
scons: Building targets …
scons: `bin’ is up to date.
scons: done building targets.Please someone tell me what should I do to fix this? Although it said that ‘bin’ is up to date and done building targets, I checked that the bin folder in the rosetta_source is empty.
Thank you for your help.
Marsia
-
-
AuthorPosts
- You must be logged in to reply to this topic.