[Ecls-list] Sparc 32 build

[Bruce O'Neel]

Hi,

One of the home systems is a old sparc 20 which recently got switched from
NetBSD to Linux.  Ecl had some build problems with the gmp library
and this is to document them to the large user community of sparc32 and ecl
users...

The summary seems to be that the tricks the gmp folks used to make the 
supersparc go fast work badly with newer gcc and/or os versions.  Everything
*seems* to work ok if you just get rid of the supersparc specific bits.


To get things to build pretty much you must comment out the lines in 
src/gmp/configure which look like:
      #sparcv8*-*-* | supersparc*-*-* | microsparc*-*-*)
      #  gcc_cflags_cpu="-mcpu=v8 -mv8"
      #  acc_cflags="-O2 -cg92"
      #  path="sparc32/v8 sparc32"
      #  extra_functions="udiv"

        #case $host in
        #  *-*-solaris2.*)  cc_cflags="-xtarget=native -xarch=v8 -xO4" ;;
        #esac
        #case $host in
        #  supersparc*-*-*) path="sparc32/v8/supersparc sparc32/v8 sparc32" ;;
        #esac
        #;;

You must do the above before you run configure.

If you just do this ecl_min will run and will only segfault on a few 
files.  You can just copy those .c and .h files from a build from another
architecture and manually compile them.

To get things to work even better, after you run configure, edit 
build/gmp/config.h and comment out HAVE_HOST_CPU_supersparc
and uncomment HAVE_HOST_CPU_sparcv8 so that it looks like:

#define  HAVE_HOST_CPU_sparcv8  1
/* #define HAVE_HOST_CPU_supersparc 1 */

then make will run all the way, and, the resulting ecl seems to work ok.

Notice that weasel word though, seems.  Looking at the comments around
the supersparc specific assembly code implies that one should use at least
some of it if you have a supersparc.  Ie, udiv might not be doing all that one 
wants.  I've not found any problems, but, this is very much a "use at your
own risk" idea.

The only other datapoint I have related to sparc 20s, is that under NetBSD
with a hypersparc (Hypersparcs are problematic on Linux), the configure
just thought we had a v8 system and not a supersparc.  Therefore none of the
supersparc specific code was called and all went well.  At a user level
the hypersparcs and supersparcs are supposed to be the same so this implies
that the supersparc specific assembly code shouldn't matter.

cheers

bruce


-- 
edoneel at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org