[Patches] [ python-Patches-1171767 ] Fix compile/link when using
Darwin 8
SourceForge.net
noreply at sourceforge.net
Tue Mar 29 01:25:16 CEST 2005
Patches item #1171767, was opened at 2005-03-28 05:13
Message generated for change (Settings changed) made by etrepum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171767&group_id=5470
Category: Macintosh
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Bob Ippolito (etrepum)
Summary: Fix compile/link when using Darwin 8
Initial Comment:
(this is the 2.4-maint backport of 1171735)
Darwin 8's headers are anal about POSIX compliance, and linking
has changed (prebinding is now deprecated, and libcc_dynamic no
longer exists). This configure patch makes things right.
----------------------------------------------------------------------
>Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 18:25
Message:
Logged In: YES
user_id=139309
nice catch! you're right, my release24-maint wasn't checked out with SSH.
I did have access to commit. Thanks.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-28 15:38
Message:
Logged In: YES
user_id=21627
Hmm; I can't see anything wrong with your user settings, so
you should have write access in theory. Can you do checkouts
using your SSH key?
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 14:23
Message:
Logged In: YES
user_id=139309
Apparently I don't have write access to this part of CVS yet, so I can't
commit this. Here's the commit message I would've used:
patch [1171767] - Darwin 8's headers disable functionality when POSIX
is enabled. This prevents the toolbox glue, all of Carbon, and various
other non-POSIX features from compiling. The POSIX symbols are
stillused by default, so turning off the #define doesn't hurt.
Additionally, linker flags have changed for Darwin 8, and are different
for Darwin 8/gcc4 (default) and Darwin 8/gcc3.3.
Approved by Anthony
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 14:09
Message:
Logged In: YES
user_id=139309
I agree, and I will fix it when the headers allow such a fix.
I just don't want to see a minor OS update break all current versions of
Python, such that we have to issue a patch and accelerate a release. I
also don't want it to be specific to Darwin 8.*, because chances are,
Darwin 9 is going to be more like Darwin 8 than previous versions... so it
makes sense to default to whatever worked most recently.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-28 14:01
Message:
Logged In: YES
user_id=21627
I'm concerned that this section in configure.in might
collect old cruft, without a chance of ever getting rid of
it. Therefore, in general, I would like to see each setting
be reconsidered every time a new OS release is made;
allowing for removal of settings for systems that are not
supported any longer.
In the specific case, this is probably fine as-is, since
"Darwin 8.*" will likely be superceded with Darwin 9.0
within a few years, at which point the issue then is
reconsidered.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 13:03
Message:
Logged In: YES
user_id=139309
I wish Apple would have an additional #define too, but they don't.
The other option sounds bad. On the first minor kernel update, Python
won't compile any more. In the manner I applied the patch, a minor kernel
update will not break anything. When they fix the headers, we can fix
Python's configure on our own schedule, since this patch won't regress
with fixed headers.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-28 12:56
Message:
Logged In: YES
user_id=21627
Ok, this is fine then. The other option would have been to
explicitly state 8.0, instead of 8.*, and extend that to
8.[01] when 8.1 is released and still shows the problem, and
so on. I really wish Apple would provide a #define to turn
on additional features.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 12:51
Message:
Logged In: YES
user_id=139309
This is an updated version of the patch. When using gcc4, libcc_dynamic
does not exist. Previous versions of gcc require it. So the linker flags are
dependent on the gcc version.
This fixes compilation on Darwin >= 8 with gcc < 4.0 (gcc 4 is the default)
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 12:04
Message:
Logged In: YES
user_id=139309
That's up to them.. I don't have access to that kind of information. We'll
know when a new set of headers are released. In my experience with
the platform, it is very rare that headers are modified in any way after
release, until the next major version. So my guess is that the problem
will still exist in 8.5.
It doesn't matter so much either way, turning these defines off doesn't
break anything. On this platform, they are used almost exclusively to
turn off behavior, not to enable or change behavior. I'm perfectly willing
to revise the patch when/if it's fixed in the headers, but I think that will
be a while.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-28 11:55
Message:
Logged In: YES
user_id=21627
I'm fine with this patch applying to 8.0 (or whatever it is
going to be called); my concern is that it is unclear
(atleast to me) whether the problem will still exist in,
say, 8.5.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 11:26
Message:
Logged In: YES
user_id=139309
I would prefer to not talk about versions that have not been released
publicly yet too (it has been in development for quite some time), but it's
going to be released with this bug, and we want Python to compile on this
platform.
I need to make some updates to these patches, and will improve the
comment at that time.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-28 10:13
Message:
Logged In: YES
user_id=21627
In the comment as to why this disables platform specific
features beyond repair, please list specific examples (e.g.
the first one that is encountered); please also put your
name as the one to ask for further details into this comment.
Also, I would prefer this not to talk about versions whose
development has not started yet (ie. 8.*), unless there is
some really strong indication that none of the 8.* releases
will provide a solution.
----------------------------------------------------------------------
Comment By: Bob Ippolito (etrepum)
Date: 2005-03-28 05:19
Message:
Logged In: YES
user_id=139309
... patch small enough to upload, using same autoconf version as what
was used by CVS
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1171767&group_id=5470
More information about the Patches
mailing list