2 Replies Latest reply on Jul 15, 2011 8:18 PM by bastl

    Unable to build Open64 4.2.5.1 on 32-bit Debian "squeeze"

    reid
      Can't build Open64 4.2.5.1 on 32-bit Debian "squeeze"

      Hi all --

      I am trying to build the latest Open64 compiler suite on 32-bit Debian "squeeze".  I have read the notes in the "INSTALL" file, and my system has the required packages.  My binutils is 2.20.1.

      I had a lot of deprecation warnings and problems with gcc-4.4, so I am trying to use gcc-4.3, which is conveniently packaged for this system.

      My steps are in the attached code, I configure without the "bulldozer" options, and with the compiler specified, and then run make.

      The build errors-out in osprey/common/com/config_cache.cxx, apparently several declarations are missing, apparently because the "#if define(_LANGUAGE_C_PLUS_PLUS)" directive in config_cache.h is not being honored.

      For the second attempt, I simply removed this #if directive and the corresponding #endif from config_cache.h -- there are two of them, one in each of the MHD-related structs.

      Re-running make leads to a subsequent failure in osprey/ipa/common/ipc_weak.h, "string does not name a type".  I started working my way through these with simple typedefs, but there are a lot of these, after string, there is int64 and uint64, and they're in several files -- case-by-case remediation scales rather poorly as a strategy.

      It looks like this is mostly a compiler-version issue, and is likely present on 64-bit also, although I haven't tried it.  It appers there is no convenient way to get gcc-4.2 on to "squeeze", is it really necessary?

       

      Edited to add:

      I have subsequently discovered the "llvm-gcc-4.2" tools which are packaged for Debian "squeeze", and tried it with those. I have the same problems, first the #if define problem, and when that is bypassed, subsequently failures with boolean, string, int16, uint16 being reported as not naming types.

      However, the llvm-gcc-4.2 build has many fewer deprecation warnings, so it seems like it's possibly a step in the right direction.

      > CC=gcc-4.3 CXX=g++-4.3 ./configure --prefix=<prefix> --disable-host_bdver1-support > MAKEFLAGS="CC=gcc-4.3 CXX=g++-4.3" make

        • Unable to build Open64 4.2.5.1 on 32-bit Debian "squeeze"
          santosh.zanjurne

          Hello Reid,

          Thanks for reporting this problem.  I shall check this out and will get back to you.

          Thanks & Regards,

          Santosh

           

          • Unable to build Open64 4.2.5.1 on 32-bit Debian "squeeze"
            bastl
            This issue lacks in the interwork of binutils and GCC.
            GCC don't want to support cross compiling from 32/32 to 64 bit and therefore Binutils don't see the need to compile ld as a 64 bit linker on a 32 bit system.

            If I guess right, then you need an other 32 bit system than linux to compile it for 64 bit.

            Maybe with BSD it is possible to handle that isue.

            I think it is best to take a yet 64 bit compiled system and compile it there.
            (knoppix seams to be a verry good development system)

            Even though you can not run 64 bit code on a system with a 32 bit kernel like the other way around even if the CPU can.

            That means to compile a minimum boot system with terminal including GCC in 64 bit without knowing if there is a compilation error because you can not run any test and checks of GCC and ld, the kernel, systools, shell, ... .

            Maybe LFS has an answer.