bug-guile
[Top][All Lists]
Advanced

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

Re: mac osx 10.2 guile 1.6.0 guile-snarf


From: Bill Schottstaedt
Subject: Re: mac osx 10.2 guile 1.6.0 guile-snarf
Date: Tue, 5 Nov 2002 04:11:03 -0800

> Could you condense this into a patch that we can apply?

For Mac OSX 10.2:

change libguile/gc_os_dep.c line 255 from

# if defined(macosx)

to

# if defined(macosx) || (defined(__APPLE__) && defined(__ppc__))


This could be

# if defined(macosx) || defined(__ppc__)

but in linuxppc, the compiler has __PPC__ predefined,
so adding __APPLE__ seems safer.

--------------------------------------------------------------------------------
change libguile/gc_os_del.c scm_get_stack_base (line 1845 ff) from

    word dummy;
    void *result = &dummy;  /* initialize to silence compiler */

#   define STACKBOTTOM_ALIGNMENT_M1 ((word)STACK_GRAN - 1)

#   ifdef STACKBOTTOM
        return(STACKBOTTOM);
#   else

to

#   ifdef STACKBOTTOM
        return(STACKBOTTOM);
#   else

    word dummy;
    void *result = &dummy;  /* initialize to silence compiler */

#   define STACKBOTTOM_ALIGNMENT_M1 ((word)STACK_GRAN - 1)

--------------------------------------------------------------------------------
In guile-core/configure.in line 379,
the false-positive for __libc_stack_end happens because the
-O2 switch optimizes out the __libc_stack_end reference:

/Users/bill/test/ more stack.c
#line 2343 "configure"
#include "confdefs.h"
extern char *__libc_stack_end;
#ifdef F77_DUMMY_MAIN
#  ifdef __cplusplus
     extern "C"
#  endif
   int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
char *p = __libc_stack_end;
  ;
  return 0;
}

/Users/bill/test/ gcc stack.c -g -O2 -o foo
/Users/bill/test/ foo

/Users/bill/test/ gcc stack.c -g -o foo
ld: Undefined symbols:
___libc_stack_end
/Users/bill/test/


I can overcome this optimization by changing the test to:


AC_MSG_CHECKING(for __libc_stack_end)
AC_TRY_LINK([#include <string.h>
            extern char *__libc_stack_end;],
            [char *p; p = strdup(__libc_stack_end);],
            have_libc_stack_end=yes,
            have_libc_stack_end=no)
AC_MSG_RESULT($have_libc_stack_end)

--------------------------------------------------------------------------------
in libguile/coop.c:

#include <stdio.h>
#include <errno.h>

#include "qt/qt.h"
#include "libguile/eval.h"
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif


(this is the same as the iselect.c change earlier).

--------------------------------------------------------------------------------
On the MISSING_SLEEP problem, gcc -E ignores "preprocessed" files;
on the Mac /usr/include/unistd.h falls into this category, whereas
/usr/include/string.h does not; so the strptime check works,
but AC_EGREP_HEADER can't be used to search unistd.h.  If we make
a program:

#include <unistd.h>

then

gcc -E eg.c

it just prints the #include line, not the contents of unistd.h.

This strikes me as an autoconf bug, and I don't find any obvious
switch in cpp/gcc to override this aspect of -E, so I just commented out
the two lines (lines 346, 347) involving sleep and usleep
(the declarations are not missing, so the check can only
screw us up).

--------------------------------------------------------------------------------
With the current CVS version, a new bug arose in threads.h:

gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../libguile-ltdl    -g -O2 -Werror 
-Wall -Wmissing-prototypes -c `test -f  
'guile.c' || echo './'`guile.c
cc1: warnings being treated as errors
In file included from ../libguile.h:132,
                 from guile.c:52:
../libguile/threads.h:150: warning: `struct timespec' declared inside parameter 
list
../libguile/threads.h:150: warning: its scope is only this definition or 
declaration, which is probably not what you want

Since the threads stuff is in flux, I just commented out the
offending declaration, and the function itself in threads.c.


And threads.c needs to include unistd.h for select.

--------------------------------------------------------------------------------
This leaves unanswered the guile-snarf problem, but its output is fine,
so its blathering can be ignored.





reply via email to

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