guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building guile on IA64 HP-UX


From: Steve Ellcey
Subject: Building guile on IA64 HP-UX
Date: Mon, 8 Jan 2007 16:12:23 -0800 (PST)

I have been trying to build guile on IA64 HP-UX off and on and wanted to
report my latest results.  This latest attempt was done using the
snapshot at

http://www.ossau.uklinux.net/guile/guile-cvs.20061113.tar.gz

created for me by Neil Jerram.  The snapshots at

ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshots

which is where the guile home page points to are all out-of-date.  The
ToT one is dated Nov 19 and the 1.6 and 1.8 ones are from early
December.  It would be very helpful if these "nightly" snapshots could
be updated.

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

Compiling with GCC:

As for my results, using GCC as a compiler, I had to modify
libguile/gc.c to add an include of <sys/uc_access.h> after the includes
of <sys/param.h> and <sys/pstat.h> (in the existing __hpux ifdef) in
order to get a definition of __uc_get_ar_bsp and I also changed:

        return (void *) bsp;

at the end of scm_ia64_ar_bsp to be:

        return (void *) (long) bsp;

These changes made some warnings go away and the warnings were stopping
the build because of the -Werror flag used with GCC.  With this change I
can compile libguile/gc.c but I get stopped in libguile/numbers.c due to
issues with the complex data type.

[evrst7] $ diff guile-1.9.0.old/libguile/gc.c guile-1.9.0/libguile/gc.c
1074a1075
> #  include <sys/uc_access.h>
1090c1091
<   return (void *) bsp;
---
>   return (void *) (long) bsp;


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

Compiling with the HP C compiler 

With the HP C compiler I fail when compiling libguile/eval.c with the
error:

"/tmp/guile/guile-1.9.0/libguile/eval.c", line 3327: error #2057: this operator
is not allowed in a constant expression
          case (ISYMNUM (SCM_IM_AND)):

It looks like this is due to the SCM_UNPACK macro.  From tags.h we have:

  /*
    The 0?: constructions makes sure that the code is never executed,
    and that there is no performance hit.  However, the alternative is
    compiled, and does generate a warning when used with the wrong
    pointer type.
   */
  #define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))

and the HP compiler doesn't seem to like the assignment operator in
the case statement.  The following simpler example will not compile
with the HP compiler (but will compile with GCC):

  unsigned long x;
  int foo(int i) {
        switch (i) {
                case ((unsigned long) (0 ? (x = 4) : 4)):
                default: return 0;
        }
  }

I am not sure if this is legal C or not but it does seem 'yucky' (if I
may use that technical term).  Anyway, I hope someone can fix up gc.c, I
will work on the complex datatype issues when I have a chance, I don't
know what, if anything, should be done with the SCM_UNPACK macro.

Steve Ellcey
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]