13 Replies Latest reply on Feb 23, 2010 11:54 PM by dgilmore

    problems building on 32-bit host

    regehr
      can't compile x86_open64-4.2.3 on i686 Ubuntu 9.10 box

      Hi folks,

      I'm having trouble building x86_open64-4.2.3 on an Ubuntu 9.10 box running in 32-bit mode.  I believe that I have followed all instructions in the INSTALL file and have looked over the existing messages on this board.

      The problem comes during the gcc-4.2.0 build and seems to be an attempt to assemble 64-bit code with 32-bit tools.

      Any help would be appreciated.  Thanks,

      John Regehr

       

      /bin/sh ../../gcc/mkconfig.sh tconfig.h
      /home/regehr/z/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/xgcc -B/home/regehr/z/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/bin/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/lib/ -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/include -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/sys-include -O2 -O2 -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../../libspin -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
      -c ../../gcc/crtstuff.c -DCRT_BEGIN \
      -o crtbegin.o
      /tmp/cc3A9IO6.s: Assembler messages:
      /tmp/cc3A9IO6.s:27: Error: bad register name `%rip)'
      /tmp/cc3A9IO6.s:28: Error: bad register name `%rbp'
      /tmp/cc3A9IO6.s:29: Error: bad register name `%rsp'
      /tmp/cc3A9IO6.s:34: Error: bad register name `%rax'
      /tmp/cc3A9IO6.s:35: Error: bad register name `%rax'
      /tmp/cc3A9IO6.s:36: Error: bad register name `%rdx'
      /tmp/cc3A9IO6.s:38: Error: bad register name `%rip)'
      /tmp/cc3A9IO6.s:39: Error: bad register name `%rax)'
      /tmp/cc3A9IO6.s:40: Error: bad register name `%rdx'
      /tmp/cc3A9IO6.s:42: Error: bad register name `%rip)'
      /tmp/cc3A9IO6.s:54: Error: bad register name `%rbp'
      /tmp/cc3A9IO6.s:55: Error: bad register name `%rip)'
      /tmp/cc3A9IO6.s:56: Error: bad register name `%rsp'
      /tmp/cc3A9IO6.s:59: Error: bad register name `%rax'
      /tmp/cc3A9IO6.s:62: Error: bad register name `%rax'
      /tmp/cc3A9IO6.s:64: Error: bad register name `%r11'
      make[4]: *** [crtbegin.o] Error 1
      make[4]: Leaving directory `/home/regehr/z/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/gcc'
      make[3]: *** [all-gcc] Error 2
      make[3]: Leaving directory `/home/regehr/z/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664'
      make[2]: *** [all] Error 2
      make[2]: Leaving directory `/home/regehr/z/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664'
      make[1]: *** [osprey-gcc-4.2.0/targia32_x8664/gcc/cc1] Error 2
      make[1]: Leaving directory `/home/regehr/z/x86_open64-4.2.3'
      make: *** [build] Error 2

        • problems building on 32-bit host
          dgilmore

          John,

          We'll need to get back to you on this one.   This problem has also been recently reported on the open64-devel list:

          http://sourceforge.net/mailarchive/forum.php?thread_name=92618b630912300806l57a4480dxd010f48ea29d17d8%40mail.gmail.com&forum_name=open64-devel

          Though it doesn't appear that a clean resolution to the problem has been found.    Hopefully sometime next week once folks return from the Holidays more people will be looking into this issue.

          Doug

            • problems building on 32-bit host
              regehr

              Thanks Doug!  I'll keep an eye on that thread as well as this one.

              John Regehr

               

                • problems building on 32-bit host
                  mvermeulen

                  If you have a 64-bit ubuntu OS available, a potential workaround is to build the compiler on 64-bit ubuntu OS and then run it on the 32-bit ubuntu OS.  Just did the equivalent scenario with Debian 5:

                  - Open64 4.2.3. builds on 64-bit Debian, following the ubuntu instructions given in the INSTALL file.

                  - Open64 4.2.3. fails to build on 32-bit Debian with same symptoms reported above.  However, copying over the compiler built on the 64-bit Debian system to the 32-bit Debian system results in a compiler that works on 32-bit Debian.

                  • problems building on 32-bit host
                    dgilmore

                    Hi John,

                    Though this patch needs some cleanup, it should hopefully should get you going in terms of build the compiler on an x86 system.

                    Let us know how things go.

                    Doug

                     

                      • problems building on 32-bit host
                        regehr

                        Thanks Doug, I'll try this tonight.

                        Unfortunately the "build on 64-bit" suggestion didn't pan out for me since the x64 systems I have access to are running an older Ubuntu.  The build failed and I ran out of time to track down the problem, thought it was no doubt something simple.

                        • problems building on 32-bit host
                          regehr

                          This patch works, thanks a ton!

                           

                          • problems building on 32-bit host
                            mathog

                            I just hit the same problem, or something very much like it, with 4.2.3 on Mandriva 2008.1.  This system already has gcc 4.2.3 and that is what was used to build this compiler.  Here is where it goes wrong:

                            mv tmp-libgcc.mk libgcc.mk
                            TARGET_CPU_DEFAULT="" \
                                    HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET " \
                                    /bin/sh ../../gcc/mkconfig.sh tconfig.h
                            /u2/beowulf/src/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/xgcc -B/u2/beowulf/src/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/bin/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/lib/ -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/include -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/sys-include -O2 -O2 -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../../libspin -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber -I../libdecnumber  -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder  -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
                                      -c ../../gcc/crtstuff.c -DCRT_BEGIN \
                                      -o crtbegin.o
                            /root/tmp/ccMLLUqr.s: Assembler messages:
                            /root/tmp/ccMLLUqr.s:27: Error: bad register name `%rip)'
                            /root/tmp/ccMLLUqr.s:28: Error: bad register name `%rbp'
                            /root/tmp/ccMLLUqr.s:29: Error: bad register name `%rsp'
                            /root/tmp/ccMLLUqr.s:34: Error: bad register name `%rax'
                            /root/tmp/ccMLLUqr.s:35: Error: bad register name `%rax'
                            /root/tmp/ccMLLUqr.s:36: Error: bad register name `%rdx'
                            /root/tmp/ccMLLUqr.s:38: Error: bad register name `%rip)'
                            /root/tmp/ccMLLUqr.s:39: Error: bad register name `%rax)'
                            /root/tmp/ccMLLUqr.s:40: Error: bad register name `%rdx'
                            /root/tmp/ccMLLUqr.s:42: Error: bad register name `%rip)'
                            /root/tmp/ccMLLUqr.s:54: Error: bad register name `%rbp'
                            /root/tmp/ccMLLUqr.s:55: Error: bad register name `%rip)'
                            /root/tmp/ccMLLUqr.s:56: Error: bad register name `%rsp'
                            /root/tmp/ccMLLUqr.s:59: Error: bad register name `%rax'
                            /root/tmp/ccMLLUqr.s:62: Error: bad register name `%rax'
                            /root/tmp/ccMLLUqr.s:64: Error: bad register name `%r11'

                             

                            The patch in this thread seems to be hard coded for version 4.2.0.  Any chance we could have one for 4.2.3, or better yet, the patch merged into the distribution?

                            Thanks.

                             

                            EDIT:  Hmm, the original was 4.2.3, maybe the 4.2.0 in the patch is somehow coded into 4.2.3 as well?  Let me check...

                            EDIT2:  With just those changes it blew up again at the same place.  Dropped into the directory where CONFIGURE was,

                              make clean

                            back to top and

                              make all MACHINE_TYPE=i386

                            and it ran for a while and then the rxvt window segfaulted.  Bizarre, I have never seen that segfault before.  I'll get back to this on Monday.

                             

                              • problems building on 32-bit host
                                dgilmore

                                > I just hit the same problem, or something very much
                                > like it, with 4.2.3 on Mandriva 2008.1.  This system
                                > already has gcc 4.2.3 and that is what was used to
                                > build this compiler.  Here is where it goes wrong:
                                >
                                > mv tmp-libgcc.mk libgcc.mk
                                > TARGET_CPU_DEFAULT="" \
                                >         HEADERS="auto-host.h ansidecl.h" DEFINES="USED_FOR_TARGET " \
                                >         /bin/sh ../../gcc/mkconfig.sh tconfig.h
                                > /u2/beowulf/src/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/xgcc -B/u2/beowulf/src/x86_open64-4.2.3/osprey-gcc-4.2.0/targia32_x8664/./gcc/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/bin/ -B/open64-gcc-4.2.0/x86_64-redhat-linux/lib/ -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/include -isystem /open64-gcc-4.2.0/x86_64-redhat-linux/sys-include -O2 -O2 -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../../libspin -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber -I../libdecnumber  -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder  -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
                                >           -c ../../gcc/crtstuff.c -DCRT_BEGIN \
                                >           -o crtbegin.o
                                > /root/tmp/ccMLLUqr.s: Assembler messages:
                                ...
                                > /root/tmp/ccMLLUqr.s:62: Error: bad register name `%rax'
                                > /root/tmp/ccMLLUqr.s:64: Error: bad register name `%r11'
                                >

                                >
                                > The patch in this thread seems to be hard coded for
                                > version 4.2.0.  Any chance we could have one for
                                > 4.2.3, or better yet, the patch merged into the
                                > distribution?

                                Note the 4.2.0 denotes the version of gcc/g++ that is
                                used as the front end parser for Open64 compiler, I
                                believe that you should not have problems building the
                                compiler with gcc 4.2.3, except for i386 build
                                targetting issues that the patch that I added to a
                                previous post addressed.

                                Did you try building the trunk of the Open64.net tree?
                                Our 4.2.3 release was merged into the trunk and the
                                i386 build targetting issues were also addressed in
                                slightly differently manner.  Could you give that a try?

                                Doug
                                >
                                > Thanks.
                                > ...

                                  • problems building on 32-bit host
                                    mathog

                                     

                                    Originally posted by: dgilmore

                                     

                                    Did you try building the trunk of the Open64.net tree? Our 4.2.3 release was merged into the trunk and the i386 build targetting issues were also addressed in slightly differently manner.  Could you give that a try?

                                     

                                     

                                     

                                     

                                    Just did.  Had to play around with it a bit but finally got it to produce some compiler files with:

                                    cd /tmp
                                    svn export https://svn.open64.net/svnroot/open64/trunk open64
                                    svn checkout  https://svn.open64.net/svnroot/open64/branches/open64-prebuild/ prebuild
                                    cp -r prebuild/lib  open64/
                                    cp -r prebuild/bin  open64/
                                    cd /usr/common/src
                                    mv /tmp/open64 open64_trunk_2_22_2010
                                    export TOOLROOT=/usr/common/src/open64_trunk_2_22_2010
                                    export PATH=$TOOLROOT/bin:$PATH
                                    cd $TOOLROOT
                                    nice -15 make all MACHINE_TYPE=i386 2>&1 | tee build_1.log
                                    nice -15 make install MACHINE_TYPE=i386 | tee install_1.log

                                    As for actually using it...

                                     opencc -o test test.c          
                                    /usr/bin/ld: cannot find -lopen64rt
                                    collect2: ld returned 1 exit status

                                    There is no open64rt.a or opn64rt.so in the tree.  Googling... Trying this to build those:

                                    make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP 2>&1 | tee build_2.log

                                    ...

                                    C      /u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32/libdwarf/../../libdwarf/dwarfdump/makename.c
                                    C      /u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32/libdwarf/../../libdwarf/dwarfdump/tag_attr.c
                                    /usr/bin/ld: cannot find -lopen64rt
                                    collect2: ld returned 1 exit status
                                    make[3]: *** [tag_attr_build] Error 1
                                    make[2]: *** [default] Error 2
                                    make[1]: *** [default] Error 2
                                    make[1]: Leaving directory `/u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32'
                                    make: *** [lib] Error 2

                                     

                                    Bit of chicken or the egg situation here if open64rt is needed to build open64rt!  Try building it with gcc:

                                    make lib MACHINE_TYPE=i386 2>&1 | tee build_3.log

                                    ok, that built!

                                    ./osprey/targia32_builtonia32/libopen64rt/libopen64rt_shared.a
                                    ./osprey/targia32_builtonia32/libopen64rt/libopen64rt.a

                                     

                                    make install MACHINE_TYPE=i386 | tee install_2.log

                                    Try the compiler again..

                                     opencc -o test test.c          

                                    and that worked.  Finally to get the libraries built by OSP, recompile using, apparently, the libraries built by gcc.  Presumably if OSP is making faster code than gcc then this should be a performance win in both the compilation and end binary.

                                    make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP 2>&1 | tee build_4.log

                                    make install MACHINE_TYPE=i386 | tee install_3.log

                                    I seem to be missing something since one would have though "lib" a subset of "all", and since it isn't, who knows what else isn't built.  Could you please post the commands needed to build this successfully from svn on a 32 bit system?

                                    Thanks.

                                      • problems building on 32-bit host
                                        mathog

                                        Looking through ./lib there seems to be a mix of 32 bit libraries built recently and 64 bit ones from the svn prebuilt.  Also the two files  libopen64rt.a and  libopen64rt_shared.a are identical and only 1384 bytes.  Is that how it is supposed to be?

                                        Hmm, in the ./bin directory all of these are the same size (305856) and have identical contents:

                                        opencc
                                        openCC
                                        opencc-4.2
                                        openCC-4.2
                                        openf90
                                        openf90-4.2
                                        openf95
                                        openf95-4.2

                                        Is there some reason there isn't just one (open64real) with symbolic links from all the others?

                                         

                                          • problems building on 32-bit host
                                            dgilmore

                                             

                                            Originally posted by: mathog Looking through ./lib there seems to be a mix of 32 bit libraries built recently and 64 bit ones from the svn prebuilt.  Also the two files  libopen64rt.a and  libopen64rt_shared.a are identical and only 1384 bytes.  Is that how it is supposed to be?

                                             

                                            Hmm, in the ./bin directory all of these are the same size (305856) and have identical contents:

                                             

                                            opencc openCC opencc-4.2 openCC-4.2 openf90 openf90-4.2 openf95 openf95-4.2

                                             

                                            Is there some reason there isn't just one (open64real) with symbolic links from all the others?

                                             

                                             

                                             

                                            Yes there is a bit of waste there that we should clean up.

                                            Doug

                                          • problems building on 32-bit host
                                            dgilmore

                                             

                                            Originally posted by: mathog
                                            Originally posted by: dgilmore

                                             

                                             

                                             

                                            Did you try building the trunk of the Open64.net tree? Our 4.2.3 release was merged into the trunk and the i386 build targetting issues were also addressed in slightly differently manner.  Could you give that a try?

                                             

                                             

                                             

                                             

                                             

                                             

                                             

                                             

                                             

                                             

                                            Just did.  Had to play around with it a bit but finally got it to produce some compiler files with:

                                             

                                            cd /tmp svn export https://svn.open64.net/svnroot/open64/trunk open64 svn checkout  https://svn.open64.net/svnroot/open64/branches/open64-prebuild/ prebuild cp -r prebuild/lib  open64/ cp -r prebuild/bin  open64/ cd /usr/common/src mv /tmp/open64 open64_trunk_2_22_2010 export TOOLROOT=/usr/common/src/open64_trunk_2_22_2010 export PATH=$TOOLROOT/bin:$PATH cd $TOOLROOT nice -15 make all MACHINE_TYPE=i386 2>&1 | tee build_1.log nice -15 make install MACHINE_TYPE=i386 | tee install_1.log

                                             

                                            As for actually using it...

                                             

                                             opencc -o test test.c           /usr/bin/ld: cannot find -lopen64rt collect2: ld returned 1 exit status

                                             

                                            There is no open64rt.a or opn64rt.so in the tree.  Googling... Trying this to build those:

                                             

                                            make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP 2>&1 | tee build_2.log

                                             

                                            ...

                                             

                                            C      /u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32/libdwarf/../../libdwarf/dwarfdump/makename.c C      /u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32/libdwarf/../../libdwarf/dwarfdump/tag_attr.c /usr/bin/ld: cannot find -lopen64rt collect2: ld returned 1 exit status make[3]: *** [tag_attr_build] Error 1 make[2]: *** [default] Error 2 make[1]: *** [default] Error 2 make[1]: Leaving directory `/u2/beowulf/src/open64_trunk_2_22_2010/osprey/targia32_builtonia32' make: *** [lib] Error 2

                                             

                                             

                                             

                                            Bit of chicken or the egg situation here if open64rt is needed to build open64rt!  Try building it with gcc:

                                             

                                            make lib MACHINE_TYPE=i386 2>&1 | tee build_3.log

                                             

                                            ok, that built!

                                             

                                            ./osprey/targia32_builtonia32/libopen64rt/libopen64rt_shared.a ./osprey/targia32_builtonia32/libopen64rt/libopen64rt.a

                                             

                                             

                                             

                                            make install MACHINE_TYPE=i386 | tee install_2.log

                                             

                                            Try the compiler again..

                                             

                                             opencc -o test test.c          

                                             

                                            and that worked.  Finally to get the libraries built by OSP, recompile using, apparently, the libraries built by gcc.  Presumably if OSP is making faster code than gcc then this should be a performance win in both the compilation and end binary.

                                             

                                            make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP 2>&1 | tee build_4.log

                                             

                                            make install MACHINE_TYPE=i386 | tee install_3.log

                                             

                                            I seem to be missing something since one would have though "lib" a subset of "all", and since it isn't, who knows what else isn't built.  Could you please post the commands needed to build this successfully from svn on a 32 bit system?

                                             

                                            Thanks.

                                             

                                            Sorry, I forgot that the build instructions on the trunk are a bit messy, I'll try to get them cleaned up.

                                            Fortunately the build instruction included with AMD's Open64 source will still work, so you can just follow the instructions in the AMD's INSTALL file, which you can grab via:

                                            svn cat https://svn.open64.net/svnroot/open64/branches/x86_open64-4.2.3/INSTALL > myinstall

                                            The only twist is that when building on i386, you will probably want to leave out building the 64-bit runtime:

                                              make -C osprey/targx8664_builtonia32 BUILD_COMPILER=OSP

                                            Note that we always build the compiler and library with the bootstrap compiler (this finesses the bootstrapping problem you mentioned).

                                            Doug