This affected me, too. After a question on the scsh-users list (see <http://lists.apple.com/archives/Unix-porting/2010/Jan/msg00000.html> and following thread), it's clear that this arises because OS X 10.6 defaults to building 64-bit executables.
I've attached a patch to 0.6.7 configure.in which adds a test for this, adding -m32 when necessary. This is specific to gcc; other suitable flags should be added here for other compilers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
+ dnl Check whether we need to force the compiler to produce
+ dnl a 32-bit object file. This appears to be enough to produce
+ dnl 32-bit executables where it matters, but if extra linker flags are
+ dnl required on some platforms, this is the place to add them.
+ dnl LONG_BIT is one of the limits.h constants required by the
+ dnl POSIX spec; is it universal? If not, LONG_MAX would probably
+ dnl be an acceptable alternative.
+ dnl The '-m32' compiler flag works for gcc.
+ AC_MSG_CHECKING(whether we need to force 32-bit)
+ cflags_orig=${CFLAGS}
+ for testcflag in '' -m32; do
+ CFLAGS="${cflags_orig} ${testcflag}"
+ AC_TRY_COMPILE([#include <limits.h>],[
+ #if LONG_BIT > 32
+ #error "Object files have a word length more than 32-bit"
+ #else
+ return 0;
+ #endif
+ ], [gotflag=:], [gotflag=false])
+ if $gotflag; then break; fi
+ done
+ if $gotflag; then
+ AC_MSG_RESULT($testcflag)
+ dnl ...and leave CFLAGS containing the successful flag
+ else
+ AC_MSG_ERROR([I can't work out how to create 32-bit executables])
+ fi
+
+
dnl Check for System V STREAM support functions.
AC_CHECK_HEADERS(stropts.h)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This affected me, too. After a question on the scsh-users list (see <http://lists.apple.com/archives/Unix-porting/2010/Jan/msg00000.html> and following thread), it's clear that this arises because OS X 10.6 defaults to building 64-bit executables.
I've attached a patch to 0.6.7 configure.in which adds a test for this, adding -m32 when necessary. This is specific to gcc; other suitable flags should be added here for other compilers.
Hah! I don't seem to be able to attach a file to this tracker item. No problem: here it is inline.
*** configure.in.orig 2010-01-20 08:54:58.000000000 +0000
--- configure.in 2010-01-20 09:56:49.000000000 +0000
***************
*** 431,436 ****
--- 431,465 ----
;;
esac
+ dnl Check whether we need to force the compiler to produce
+ dnl a 32-bit object file. This appears to be enough to produce
+ dnl 32-bit executables where it matters, but if extra linker flags are
+ dnl required on some platforms, this is the place to add them.
+ dnl LONG_BIT is one of the limits.h constants required by the
+ dnl POSIX spec; is it universal? If not, LONG_MAX would probably
+ dnl be an acceptable alternative.
+ dnl The '-m32' compiler flag works for gcc.
+ AC_MSG_CHECKING(whether we need to force 32-bit)
+ cflags_orig=${CFLAGS}
+ for testcflag in '' -m32; do
+ CFLAGS="${cflags_orig} ${testcflag}"
+ AC_TRY_COMPILE([#include <limits.h>],[
+ #if LONG_BIT > 32
+ #error "Object files have a word length more than 32-bit"
+ #else
+ return 0;
+ #endif
+ ], [gotflag=:], [gotflag=false])
+ if $gotflag; then break; fi
+ done
+ if $gotflag; then
+ AC_MSG_RESULT($testcflag)
+ dnl ...and leave CFLAGS containing the successful flag
+ else
+ AC_MSG_ERROR([I can't work out how to create 32-bit executables])
+ fi
+
+
dnl Check for System V STREAM support functions.
AC_CHECK_HEADERS(stropts.h)
Grr: thwarted by sourceforge workflows again.
I've added patch 2935530 to the tracker (which is of course what I should have done in the first place, bah, mutter...)
An alternative to Norman's patch is to include -m32 in the CFLAGS specification when running configure:
./configure CFLAGS="-m32 other g/cc flags".