Patches item #1171767, was opened at 2005-03-28 05:13 Message generated for change (Comment added) 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: Open Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Anthony Baxter (anthonybaxter) 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 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 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
