./configure --enable-framework --enable-universalsdk fails because of change in r63997

[trentm]

BPO	3381
Nosy	@birkenfeld, @ronaldoussoren, @benjaminp
Files	configure-patch-3381.txt configure-patch-3381-1.txt configure-patch-3381-2.txt issue3381_configure_fix.patch: tweak to svn head to fix "configure-patch-3381-2.txt"

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ronaldoussoren'
closed_at = <Date 2008-07-22.07:07:20.196>
created_at = <Date 2008-07-16.17:37:36.913>
labels = ['deferred-blocker', 'build']
title = '`./configure --enable-framework --enable-universalsdk` fails because of change in r63997'
updated_at = <Date 2008-07-22.07:11:19.352>
user = 'https://bugs.python.org/trentm'

bugs.python.org fields:

activity = <Date 2008-07-22.07:11:19.352>
actor = 'trentm'
assignee = 'ronaldoussoren'
closed = True
closed_date = <Date 2008-07-22.07:07:20.196>
closer = 'ronaldoussoren'
components = ['Build']
creation = <Date 2008-07-16.17:37:36.913>
creator = 'trentm'
dependencies = []
files = ['10912', '10913', '10923', '10956']
hgrepos = []
issue_num = 3381
keywords = ['patch']
message_count = 16.0
messages = ['69805', '69817', '69819', '69820', '69823', '69827', '69828', '69832', '69871', '69883', '69935', '69936', '70114', '70115', '70138', '70139']
nosy_count = 4.0
nosy_names = ['georg.brandl', 'ronaldoussoren', 'benjamin.peterson', 'trentm']
pr_nums = []
priority = 'deferred blocker'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue3381'
versions = ['Python 2.6']

[trentm]

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

[ronaldoussoren]

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.

[ronaldoussoren]

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.

[ronaldoussoren]

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.

[ronaldoussoren]

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.

[trentm]

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

[ronaldoussoren]

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
bpo-3381 when I fixed the "configure should use the right CFLAGS" issue
for 10.5 and my patch for bpo-3381 doesn't change the compiler flags on
10.5.

[trentm]

Yet another version: configure-patch-3381-2.txt is a slight enhancement
of the first version.

Ronald,
Did that accidentally not get attached?

[ronaldoussoren]

Forgot to upload updated patch

[benjaminp]

Ok applied in r65061.

[ronaldoussoren]

Whoops, bpo-3393 is a duplicate of this issue and notes that
Mac/IDLE/Makefile.in is also affected.

I've fixed that makefile in r65091.

[trentm]

Ronald,

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

[trentm]

This bug should be re-opened. The patch to configure.in wasn't quite
right. I'm attaching a slight fix. autoconfing 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?)

[birkenfeld]

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

[ronaldoussoren]

Committed in r65183.

[trentm]

Thanks Ronald.

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