Mac OS X painless compilation

[boredzo]

BPO	719549
Nosy	@jackjansen

^{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/jackjansen'
closed_at = <Date 2003-05-20.23:45:37.000>
created_at = <Date 2003-04-11.08:36:11.000>
labels = ['invalid', 'docs']
title = 'Mac OS X painless compilation'
updated_at = <Date 2003-05-20.23:45:37.000>
user = 'https://bugs.python.org/boredzo'

bugs.python.org fields:

activity = <Date 2003-05-20.23:45:37.000>
actor = 'boredzo'
assignee = 'jackjansen'
closed = True
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2003-04-11.08:36:11.000>
creator = 'boredzo'
dependencies = []
files = []
hgrepos = []
issue_num = 719549
keywords = []
message_count = 6.0
messages = ['15433', '15434', '15435', '15436', '15437', '15438']
nosy_count = 2.0
nosy_names = ['jackjansen', 'boredzo']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue719549'
versions = ['Python 2.2']

[boredzo]

under Mac OS X 10.1, python builds without a hitch.

I'd think that it would also build under 10.2 as well, although I don't know because I've never built it on 10.2 (I don't have it).

[jackjansen]

Logged In: YES
user_id=45365

Uhm... As this bug report bascially says "There's no problem", I assume you are referring to something in the documentation (or readme? Something else?) that states that there are problems on OSX. Could you point out where this is, or otherwise clarify your report, please?

[boredzo]

Logged In: YES
user_id=711099

not exactly. I am referring to the readme for the UNIX python interpreter, but it does not say there is a problem. the relevant portion is below.

--- BEGIN
Platform specific notes
-----------------------

(Some of these may no longer apply. If you find you can build Python
on these platforms without the special directions mentioned here,
submit a documentation bug report to SourceForge (see Bug Reports
above) so we can remove them!)
END---

there is a flaw in the Mac OS X entry, though (which I just found looking at it again now):

---BEGIN
The tests will crash on both 10.1 and 10.2 with SEGV in test_re and test_sre due to the small default stack size.
END---

judging from the rest of that paragraph, it seems that that only applies if you're using tcsh or another *csh when you configure. I used zsh (which comes with both 10.1 and 10.2) and, as I said, it built without a hitch.

[jackjansen]

Logged In: YES
user_id=45365

Thanks for the clarification. It is indeed possible that this was fixed at some
point, I will look into it.

[jackjansen]

Logged In: YES
user_id=45365

For me the bug still exists, both with zsh and tcsh, so I'm keeping the note
in because there is at least one machine where the problem occurs:-)

Let me guess: do you have a limit stacksize call in your profile or elsewhere?
Or maybe the limit is changed in /etc/profile? The default stack size limit on
OSX is 512KB, and this is not enough for test_re.

Note that this bug has been fixed in 2.3, but not in 2.2.X.

[boredzo]

Logged In: YES
user_id=711099

I did find one call to ulimit (grep -r ulimit /etc /usr), in rc.common. but all it does is set the size of core dumps, not the stack. nothing is setting the size of the stack.

I tried it from zsh 3.0.8 just now (I usually run 4.0.6) and it did SIGSEGV on test_re during a make test. but, I didn't do a make test before, so this might mean nothing. I'll try it in 4.0.6 tonight.

now that we have that cleared up...