Weak linking support for OSX

[ronaldoussoren]

BPO	1471925
Nosy	@loewis, @ronaldoussoren
Files	weaklinking.patch weaklinking-2.patch weaklinking-3.patch

^{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 2006-04-23.11:59:52.000>
created_at = <Date 2006-04-17.19:49:03.000>
labels = ['extension-modules']
title = 'Weak linking support for OSX'
updated_at = <Date 2006-04-23.11:59:52.000>
user = 'https://github.com/ronaldoussoren'

bugs.python.org fields:

activity = <Date 2006-04-23.11:59:52.000>
actor = 'ronaldoussoren'
assignee = 'ronaldoussoren'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2006-04-17.19:49:03.000>
creator = 'ronaldoussoren'
dependencies = []
files = ['7174', '7175', '7176']
hgrepos = []
issue_num = 1471925
keywords = ['patch']
message_count = 8.0
messages = ['50048', '50049', '50050', '50051', '50052', '50053', '50054', '50055']
nosy_count = 2.0
nosy_names = ['loewis', 'ronaldoussoren']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1471925'
versions = []

[ronaldoussoren]

The "itch" that is scratched by this patch is the wish to be able to use a
python binary that was build on OSX 10.4 on OSX 10.3 systems. At the
same time the binary should offer full access to OSX 10.4 API's when
running on that system.

This patch weakly links a number of functions in the posix, time and
socket modules.

I'm not quite happy with code duplication in the time and socket modules,
but don't quite know how to fix that.

[ronaldoussoren]

Logged In: YES
user_id=580910

I should not that I haven't checked this patch on other platforms than osx 10.4/
intel.

[loewis]

Logged In: YES
user_id=21627

The patch looks fine to me. I wonder why you are clearing
the errors from PyObject_DelAttrString, though: There
shouldn't be any errors (right?), so if that fails,
something is seriously wrong.

As for the time changes: are you saying OSX doesn't have
gettimeofday? I can find a manual page on

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/gettimeofday.2.html

This has higher resolution than ftime, and also takes higher
precedence in timemodule.c: Why is it not used?

[ronaldoussoren]

Logged In: YES
user_id=580910

Good points. I was clearing errors because it seemed better to ignore errors.
But you're right, if this does fail somethings is seriously wrong. I've replaced
error-checking by return statements (but have not replaced the patch).

The change to time is interesting, I added those changes because the binary 
wouldn't run without the patch, without realizing that configure/timemodule 
is picking up the wrong function for finding the current time.  That seems to 
be caused by a bug in the preprocessor code that selects the right section of 
code. OSX 10.4 has both gettimeofday and ftime, and with the current set of 
#if statements this means both the gettimeofday and ftime blocks get 
compiled in. The ftime-bit is dead code, but present nonetheless.

I tried to rearange the #if-statements to make sure just one block gets
included, but then get compiler warnings because floattime checks for an
error-return of gettimeofday. IMHO the error-return check is rather lame,
the only reason this could fail is when the first argument of gettimeofday is
invalid (and SUS says this function will always return 0, although manpage on
darwin and linux claim otherwise), And time(2) can also return -1 to indicate
failure ;-)

If uploaded a new patch (version 2) that removes error clearing for the DelAttr
calls in posixmodule and chickens out on the ftime issue by #undef-ing
HAVE_FTIME for OSX systems that HAVE_GETTIMEOFDAY.

SUS: http://www.opengroup.org/onlinepubs/007908799/xsh/
gettimeofday.html

[ronaldoussoren]

Logged In: YES
user_id=580910

Version 3 solves the ftime issue the other (IMO more correct) way: it ignores the
returnvalue of gettimeofday and conditionalizes the floattime code in such way
that either gettimeofday or ftime is used, but never both.

[loewis]

Logged In: YES
user_id=21627

The patch is fine(*). Please do add a comment to the time
implementation to elaborate on the story of return values,
and why falling back should not be done (it ought not be
necessary, on systems where it is necessary, it might not
help, and it will hurt the OSX port).

One more bit on return values: gettimeofday can indeed fail
on Linux, and also when there is a TZ problem. OTOH, ftime
is implemented on top of gettimeofday (sic), and will then
fail for the same reason. I haven't looked at the time
implementation.

If you want to be really cautious, you could return 0.0 in
case the functions fail. The only caller of floattime will
then raise an IOError.

[ronaldoussoren]

Logged In: YES
user_id=580910

Thanks for the review. I will apply this patch this weekend, including the
additional documentation in the time module.

[ronaldoussoren]

Logged In: YES
user_id=580910

I've checked in weaklinking-2.patch with a better comment. This is the version
that #undefs HAVE_FTIME on OSX. I've checked in this version instead of the
newer one because a comment in floattime claims that gettimeofday does
actually fail on some platforms.

Checked in as revision 45660