guile-devel
[Top][All Lists]
Advanced

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

Re: guile on mac OSX


From: Seth Alves
Subject: Re: guile on mac OSX
Date: Sat, 28 Jul 2001 14:17:34 -0700

Marius Vollmer <address@hidden>:
>> "macosx" wasn't defined, so I changed a line in gc_os_dep.c.  This
>> probably isn't right... maybe I don't need the __ppc__ part?
>I don't know.  The way I read the code, it wants a definite indication
>that it is compiled on MacOS X, not on a PowerPC Apple.  Maybe there
>is some other preprocessor symbol defined?

When calling either cpp, cc gives -D arguments for these:
        #define __MACH__ 1 
        #define __NATURAL_ALIGNMENT__ 1 
        #define __APPLE__ 1 
        #define __GNUC_MINOR__ 95 
        #define __ppc__ 1 
        #define __GNUC__ 2 
        #define __STDC__ 1 
        #define __DYNAMIC__ 1 
        #define __APPLE_CC__ 926 
        #define __BIG_ENDIAN__ 1 

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

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

>> 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 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:

    $ ./autogen.sh
    ...
    $ ./configure --enable-maintainer-mode
    checking how to run the C preprocessor... cc -E -traditional-cpp
    ...
    checking for usleep... yes
    ...
    checking for sleep declaration... no
    checking for usleep declaration... no
    checking return type of usleep... int

which is wrong.  sleep and usleep are declared in by unistd.h, but
the test returns the wrong answer, so they are prototyped in guile
code, and then I get duplicate and conflicting prototypes.

This test is done by GUILE_FUNC_DECLARED which calls AC_EGREP_HEADER
which calls AC_EGREP_CPP which makes conftest.c:
    #line 9758 "configure"
    #include "confdefs.h"
    #include <unistd.h>
and then does (I've removed blank lines)
    $ cc -E conftest.c                 
    #1 "configure"
    #9757 "configure"
    #1 "confdefs.h" 1
    #9758 "configure" 2
    #1 "/usr/include/unistd.h" 1
    #9759 "configure" 2
which it pipes through egrep "sleep"; egrep gets no hits.  If I run
    $ cc -E -traditional-cpp conftest.c
    ...
    unsigned int     sleep  (unsigned int)  ;
    void     usleep  (unsigned int)  ;
it works.  I'm not sure why the configure script appears to know
about -traditional-cpp but doesn't use it in that test.  The
"precompilation preprocessor" also complains to stderr sometimes.
I see this in config.log

    configure:2330: checking how to run the C preprocessor
    configure:2357: cc -E  conftest.c
    configure:2354: undefined type, found `Syntax'
    configure:2354: illegal external declaration, missing `;' after `error'
    cpp-precomp: warning: errors during smart preprocessing, retrying in basic 
mode
    configure:2363: $? = 0
    configure:2390: cc -E  conftest.c
    configure:2387: header file 'ac_nonexistent.h' not found
    cpp-precomp: warning: errors during smart preprocessing, retrying in basic 
mode
    configure:2396: $? = 1
    configure: failed program was:
    #line 2386 "configure"
    #include "confdefs.h"
    #include <ac_nonexistent.h>
    configure:2433: result: cc -E


cc can take a -traditional flag (rather than -traditional-cpp)
    $ cc -E -traditional conftest.c | egrep sleep
    unsigned int     sleep ();
    void     usleep ();
    $ cc -E -traditional-cpp conftest.c | egrep sleep
    unsigned int     sleep  (unsigned int)  ;
    void     usleep  (unsigned int)  ;
    $ cc -E conftest.c | egrep sleep                 
    $ 

The -traditional flag is a k&r vs ansi thing, and doesn't
really help, overall.

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

>> When it was time to make libguile.la, this happened:
>> [libltdlc linked twice]
>Looks like a libtool issue to me.

Yeah, I think so.  I notice that the same thing happens on my
linux machine, where the linker is perfectly happy with it.

>> After that, guile built and it started doing the texi snarfing.   This
>> died because zsh (OSX's /bin/sh) is doing a weird thing with this line
>>       exec $program ${1+"$@"}
>> which is in libtool's wrapper script for guile.
>Likewise.

Either a libtool or a zsh issue.

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

>> 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

>> regex-posix.c: In function `scm_regexp_exec':
>> regex-posix.c:281: warning: cast to pointer from integer of different size
>> regex-posix.c:282: warning: cast to pointer from integer of different size
>I don't understand this one.  Are you on a 64bit machine?

Uh... I don't know!  It's a g4 tower.  Anyway, since my last cvs
update, I'm not seeing this warning...?

        -seth



reply via email to

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