SCons compilation error (Windows XP, 32bit)

Member Site Forums Rosetta 3 Rosetta 3 – General SCons compilation error (Windows XP, 32bit)

Viewing 25 reply threads
  • Author
    Posts
    • #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) – 32bit

        Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
        (Intel)] on win32

        SCons by Steven Knight et al.: engine: v1.2.0.r3842, 2008/12/20 22:59:52,
        by scons on scons-dev

        MinGW 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
        _options

        scons: warning: The EnumOption() function is deprecated; use the
        EnumVariable()
        function instead.
        File “C:rosetta3rosetta3_sourcetoolsbuildsetup.py”, line 48, in
        setup_build
        _options

        scons: 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>

        ======================================================================

      • #4129
        Anonymous

          __push__

          (:sad:)

        • #4133
          Anonymous

            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.

          • #4137
            Anonymous

              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?

            • #4142
              Anonymous

                Thanks for your hint, smlewis.

                I will try to fix that today and post the solution here.

              • #4154
                Anonymous

                  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”,

                • #4155
                  Anonymous

                    Sorry, the post keeps getting cut off. If it doesn’t make sense, let me know.
                    -Brett

                  • #4166
                    Anonymous

                      Thanks alot “smlewis” and Brett for your replies!

                      Scons is now running – but no executable files are created during compilation run…

                      Any ideas?

                      (:redface:)

                    • #4172
                      Anonymous

                        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.

                      • #4173
                        Anonymous

                          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_options

                          scons: warning: The EnumOption() function is deprecated; use the EnumVariable()
                          function instead.
                          File “C:rosetta3_Bundlesrosetta3_source.tarrosetta3_sourcetoolsbuildsetup.
                          py”, line 48, in setup_build_options

                          scons: 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 =============================

                        • #4174
                          Anonymous

                            The output text formatting is a mess …
                            sorry for that!

                            (:confused:)

                          • #4176
                            Anonymous

                              “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.

                            • #4178
                              Anonymous

                                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?

                              • #4180
                                Anonymous

                                  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.

                                • #4184
                                  Anonymous

                                    Nope, I haven’t touched that file –
                                    only the __setup_platforms.py__ (platform not recognized problem).

                                    Everything else is out-of-the-box.

                                  • #4185
                                    Anonymous

                                      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 :)

                                    • #4186
                                      Anonymous

                                        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.

                                        • #4189
                                          Anonymous

                                            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.

                                        • #4206
                                          Anonymous

                                            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

                                          • #4208
                                            Anonymous

                                              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/

                                              • #4216
                                                Anonymous

                                                  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.

                                              • #4210
                                                Anonymous

                                                  I will try that ASAP.
                                                  Thank you for your help
                                                  (:razz:)
                                                  and have a nice weekend

                                                  • #4213
                                                    Anonymous

                                                      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 :)

                                                  • #4214
                                                    Anonymous

                                                      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 :)

                                                    • #4215
                                                      Anonymous

                                                        Sorry for the duplicate posts; I swear the “next page” link wasn’t there before… (:eek:)

                                                      • #4220
                                                        Anonymous

                                                          (: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 status

                                                          scons: *** [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?

                                                        • #4221
                                                          Anonymous

                                                            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.

                                                          • #4238
                                                            Anonymous

                                                              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 bangkok

                                                              Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)

                                                              Cheers

                                                            • #4498
                                                              Anonymous

                                                                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

                                                            Viewing 25 reply threads
                                                            • You must be logged in to reply to this topic.