* fports.c (fport_seek): Make dependent on GUILE_USE_64_CALLS.

* _scm.h: Make definition of CHOOSE_LARGEFILE depend on
GUILE_USE_64_CALLS.

* configure.in (--without-64-calls): New option.

ChangeLog

@@ -1,3 +1,7 @@
+2008-02-05  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* configure.in (--without-64-calls): New option.
+
 2008-01-30  Neil Jerram  <neil@ossau.uklinux.net>
 
 	* pre-inst-guile.in (dyld_prefix), pre-inst-guile-env.in

NEWS

@@ -49,6 +49,8 @@ backtrace of a stack with a promise object (made by `delay') in it.
 ** Fixed a segmentation fault which occurred when hashx-ref or hashx-set! was
 called with an associator proc that returns neither a pair nor #f.
 ** Secondary threads now always return a valid module for (current-module).
+** Avoid MacOS build problems caused by incorrect combination of "64"
+system and library calls.
 
 * New modules (see the manual for details)
 

configure.in

@@ -173,6 +173,47 @@ AC_ARG_ENABLE(elisp,
   [  --disable-elisp         omit Emacs Lisp support],,
   enable_elisp=yes)
 
+dnl  Added the following configure option in January 2008 following
+dnl  investigation of problems with "64" system and library calls on
+dnl  Darwin (MacOS X).  The libguile code (_scm.h) assumes that if a
+dnl  system has stat64, it will have all the other 64 APIs too; but on
+dnl  Darwin, stat64 is there but other APIs are missing.
+dnl 
+dnl  It also appears, from the Darwin docs, that most system call APIs
+dnl  there (i.e. the traditional ones _without_ "64" in their names) have
+dnl  been 64-bit-capable for a long time now, so it isn't necessary to
+dnl  use "64" versions anyway.  For example, Darwin's off_t is 64-bit.
+dnl 
+dnl  A similar problem has been reported for HP-UX:
+dnl  http://www.nabble.com/Building-guile-1.8.2-on-hpux-td13106681.html
+dnl 
+dnl  Therefore, and also because a Guile without LARGEFILE64 support is
+dnl  better than no Guile at all, we provide this option to suppress
+dnl  trying to use "64" calls.
+dnl 
+dnl  It may be that for some 64-bit function on Darwin/HP-UX we do need
+dnl  to use a "64" call, and hence that by using --without-64-calls we're
+dnl  missing out on that.  If so, someone can work on that in the future.
+dnl  For now, --without-64-calls allows Guile to build on OSs where it
+dnl  wasn't building before.
+AC_ARG_WITH([64-calls],
+  AC_HELP_STRING([--without-64-calls],
+                 [don't attempt to use system and library calls with "64" in their names]),
+  [use_64_calls=$withval],
+  [use_64_calls=yes
+   case $host in
+     *-apple-darwin* )
+       use_64_calls=no
+       ;;
+   esac])
+echo "use_64_calls=$use_64_calls"
+case "$use_64_calls" in
+  y* )
+    AC_DEFINE(GUILE_USE_64_CALLS, 1,
+      [Define to 1 in order to try to use "64" versions of system and library calls.])
+    ;;
+esac
+
 #--------------------------------------------------------------------
 
 dnl Check for dynamic linking

libguile/ChangeLog

@@ -1,3 +1,10 @@
+2008-02-05  Neil Jerram  <neil@ossau.uklinux.net>
+
+	* fports.c (fport_seek): Make dependent on GUILE_USE_64_CALLS.
+
+	* _scm.h: Make definition of CHOOSE_LARGEFILE depend on
+	GUILE_USE_64_CALLS.
+
 2008-02-01  Neil Jerram  <neil@ossau.uklinux.net>
 
 	* modules.c (the_root_module): Moved before scm_current_module.

libguile/_scm.h

@@ -114,7 +114,7 @@
 
 
 
-#if HAVE_STAT64
+#if GUILE_USE_64_CALLS && HAVE_STAT64
 #define CHOOSE_LARGEFILE(foo,foo64)     foo64
 #else
 #define CHOOSE_LARGEFILE(foo,foo64)     foo

libguile/fports.c

@@ -667,7 +667,7 @@ fport_seek_or_seek64 (SCM port, off_t_or_off64_t offset, int whence)
    case on NetBSD apparently), then fport_seek_or_seek64 is right to be
    fport_seek already.  */
 
-#if HAVE_STAT64 && SIZEOF_OFF_T != SIZEOF_OFF64_T
+#if GUILE_USE_64_CALLS && HAVE_STAT64 && SIZEOF_OFF_T != SIZEOF_OFF64_T
 static off_t
 fport_seek (SCM port, off_t offset, int whence)
 {