Re: guile on mac OSX

[Marius Vollmer]

Seth Alves <address@hidden> writes:

> Perhaps
>  # if defined(__MACH__) && defined(__APPLE__) && defined(__ppc__)

Yes, I would add

    #if !defined(macosx)
    #if defined(__MACH__) && defined(__APPLE__) && defined(__ppc__)
    #define macosx
    #endif
    #endif

somewhere near the top.

> ======================================================================
> ======================================================================
> ======================================================================
>
> >> The compiler doesn't like intptr_t or uintptr_t in bitwise or
> >> arithmetic operations, so [...]
> >What?  Can you show the error messages?  Off hand, I would say that
> >uintptr_t is buggy on MacOS X, then.
> 
> Oh, I guess it's just bitwise operations that wont compile.
> 
>     #include <stdint.h>
>     int main()
>     {
>       intptr_t p;
>       p & 1;
>       p << 1;
>       p + 1;
>     }
> 
>     cc ptr.c
>     ptr.c: In function `main':
>     ptr.c:6: invalid operands to binary &
>     ptr.c:7: invalid operands to binary <<
>     Compilation exited abnormally with code 1 at Sat Jul 28 11:09:12
> 
> I get about a zillion of those while building guile.  They are typedefed
> like this:
>     typedef int                     *intptr_t;
>     typedef unsigned long           *uintptr_t;
> and it looks like this compiler wont allow any pointer types
> in bitwise operations.

The definitions look wrong, to my limited knowledge.  intptr_t and
uintptr_t should be signed and unsigned _integer_ types that guarantee
for any pointer p that

   (void *)p == (void *)((intptr_t)p)
   (void *)p == (void *)((uintptr_t)p)   

intptr_t and uintptr_t are _not_ pointer types.

> ======================================================================
> ======================================================================
> ======================================================================
>
> >> The default cpp does some stuff I didn't expect it to, and it breaks
> >> many of the autoconf tests.  It also causes a lot of spew during
> >> guile-snarf.
> >Hmm, we had some trouble with the new CPP from gcc-3.0, I think, but
> >they ought to be fixed.  Can you show the error messages that you are
> >getting?
> 
> an example: [...]

Can you take this to the autoconf guys?  It doesn't seem to have much
to do with Guile, and I, at least, wouldn't know what to do about
it...
 
> ======================================================================
> ======================================================================
> ======================================================================
> 
> >> In file included from numbers.c:4268:
> >> ../libguile/num2integral.i.c: In function `scm_num2ptrdiff':
> >> ../libguile/num2integral.i.c:24: warning: decimal constant is so large 
> >> that it is unsigned
> >> ../libguile/num2integral.i.c:43: warning: decimal constant is so large 
> >> that it is unsigned
> >> ../libguile/num2integral.i.c: In function `scm_i_ptrdiff2big':
> >> ../libguile/num2integral.i.c:123: warning: decimal constant is so large 
> >> that it is unsigned
> >This looks like a buggy definition of PTRDIFF_MIN and PTRDIFF_MAX to
> >me, but I don't know.
> 
>     $ grep PTRDIFF_MIN /usr/include/*.h
>     /usr/include/stdint.h:#define PTRDIFF_MIN       INT32_MIN
>     $ grep 'define INT32_MIN' /usr/include/*.h
>     /usr/include/stdint.h:#define INT32_MIN        -2147483648
>     $ grep PTRDIFF_MAX /usr/include/*.h
>     /usr/include/stdint.h:#define PTRDIFF_MAX       INT32_MAX
>     $ grep 'define INT32_MAX' /usr/include/*.h
>     /usr/include/stdint.h:#define INT32_MAX        +2147483647

Aha, I have 

    #define PTRDIFF_MIN             (-2147483647-1)

on my box (GNU libc-2.2.3).  It looks like the number -2147483648 is
parsed as "-" and "2147483648" and the second part is too big for a
signed int.  The compiler doesn't know that it is going to be negated,
so it complains.  This fix is to use -2147483647-1, which doesn't
overflow signed int temporarily.