You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
./configure --enable-framework --enable-universalsdk fails because of change in r63997 #47631
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=<Date2008-07-22.07:07:20.196>created_at=<Date2008-07-16.17:37:36.913>labels= ['deferred-blocker', 'build']
title='`./configure --enable-framework --enable-universalsdk` fails because of change in r63997'updated_at=<Date2008-07-22.07:11:19.352>user='https://bugs.python.org/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:
...
----------------------------
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.
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)?
changed the title [-]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/-][+]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/+]on Jul 16, 2008
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 commented on Jul 16, 2008
trentmmannequin
MannequinAuthor
More actions
Yet another version: configure-patch-3381-2.txt is a slight enhancement
of the first version.
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 commented on Jul 21, 2008
trentmmannequin
MannequinAuthor
More actions
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?)
Activity
trentm commentedon Jul 16, 2008
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:
----------------------------
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:
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 commentedon Jul 16, 2008
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 commentedon Jul 16, 2008
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 commentedon Jul 16, 2008
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 commentedon Jul 16, 2008
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 commentedon Jul 16, 2008
Thanks for the quick patches. Other than verifying that
configure && makeworks on 10.4 what specifically should I do "to ensure thattests are done using the right SDK" (as you said in an earlier
comment)?
[-]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/-][+]`./configure --enable-framework --enable-universalsdk` fails because of change in r63997[/+]ronaldoussoren commentedon Jul 16, 2008
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 commentedon Jul 16, 2008
Ronald,
Did that accidentally not get attached?
ronaldoussoren commentedon Jul 17, 2008
Forgot to upload updated patch
benjaminp commentedon Jul 17, 2008
Ok applied in r65061.
ronaldoussoren commentedon Jul 18, 2008
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 commentedon Jul 18, 2008
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 commentedon Jul 21, 2008
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 ofsquare 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 commentedon Jul 21, 2008
Reopening. Yes, "Status" is settable only by Developers, but as a
committer, you should certainly have that privilege.
ronaldoussoren commentedon Jul 22, 2008
Committed in r65183.
trentm commentedon Jul 22, 2008
Thanks Ronald.
Any comment on http://bugs.python.org/msg69936