homepage

Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86
because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).
The failure looks like this:
----------------------------
$ ./configure --enable-framework --enable-universalsdk
...
checking for log1p... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
See `config.log' for more details.
----------------------------
And the appropriate details in config.log are:
----------------------------
...
configure:21540: checking size of wchar_t
configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c >&5
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
directory)
configure:21878: $? = 1
configure: program exited with status 1
configure: failed program was:
...
----------------------------
The command being run:
 gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c
is "$ac_link". Here is a dump of relevant variables at that point in
"configure":
------------------
LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk "
CFLAGS is "-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2"
CPPFLAGS is ""
CC is "gcc"
ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS >&5"
------------------
The problem is that r63997
(http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
added this line to "configure.in" for Mac OS X:
 CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
That results in the failure above: "ld" complaining about
-isysroot/-syslibroot being specified twice on the command line.
Ronald,
What was the "build issue on OSX 10.4" that the was meant to be fixed.
Can it be fixed without that "configure" change to "CFLAGS"?

This is rather annoying, gcc doesn't accept multipe -isysroot flags on 
10.4, yet we need to specify -isysroot during configure to ensure that 
tests are done using the right SDK, otherwise most of configure will use 
the system headers instead of the SDK specified using the --enable-
universalsdk option.
I'm currently trying to teach configure to only add -isysroot to the 
configure-time CFLAGS when the OS version is 10.5 or later, because 
that's the only platform where -isysroot is really needed in the 
configure-time CFLAGS.
The patch should be ready later tonight, I'll post it here instead of 
committing to avoid interfering with the release process.

configure-patch-3381.txt should fix the issue, but I cannot test on 10.4 
as I recently had to convert my only 10.4 machine to 10.5.

Note to self: never rush a patch
configure-patch-3881-1.txt is the better patch, the other looks right but 
using square brackets which don't survive autoconf.
BTW. the patch is only for configure.in, run autoconf to update the actual 
configure script.

Yet another version: configure-patch-3381-2.txt is a slight enhancement 
of the first version.
This version also moves the calculation of MACOSX_DEPLOYMENT_TARGET a 
lot 
earlier in configure.in, to ensure that the right value is active 
whenever
the compiler is used.
This turns out to be necessary to build using the 10.4 SDK on OSX 10.5.
BTW. Feel free to commit if the patch works for you, I'm rather swamped 
at work and won't be able to test on 10.4 anytime soon.

> BTW. Feel free to commit if the patch works for you, I'm rather swamped
> at work and won't be able to test on 10.4 anytime soon.
Thanks for the quick patches. Other than verifying that `configure &&
make` works on 10.4 what specifically should I do "to ensure that
tests are done using the right SDK" (as you said in an earlier
comment)?

The easiest way to test the configure bits would be to build on 10.5 with 
--enable-universalsdk and --enable-universalsdk=/. Both should work on 
10.5, while using different SDKs (with slightly different unix APIs).
However: it shouldn't be necessary to test that specific bit, I introduced 
issue3381 when I fixed the "configure should use the right CFLAGS" issue 
for 10.5 and my patch for issue3381 doesn't change the compiler flags on 
10.5.

> Yet another version: configure-patch-3381-2.txt is a slight enhancement
> of the first version.
Ronald,
Did that accidentally not get attached?

Forgot to upload updated patch

Ok applied in r65061.

Whoops, issue 3393 is a duplicate of this issue and notes that 
Mac/IDLE/Makefile.in is also affected.
I've fixed that makefile in r65091.

Ronald,
The @ARCH_RUN_32BIT@ also needs to be added to two places in
Mac/Makefile.in (as indicated in issue 3393), no? Would you like me to
make that change?

This bug should be re-opened. The patch to configure.in wasn't quite
right. I'm attaching a slight fix. `autoconf`ing removes one level of
square brackets in the 'sed' command to create $tgt.
(Q about the issue tracker: I'm unable to change the "Status" field on
this bug. I'm guessing that is "by design", right? I.e., only certain
people have the privs to change bug status?)

Reopening. Yes, "Status" is settable only by Developers, but as a
committer, you should certainly have that privilege.

Committed in r65183.

Thanks Ronald.
Any comment on http://bugs.python.org/msg69936