[Python-bugs-list] [Bug #110623] build on NeXTStep (PR#240)
noreply@sourceforge.net
noreply@sourceforge.net
Sat, 5 Aug 2000 11:54:56 -0700
Bug #110623, was updated on 2000-Jul-31 14:07
Here is a current snapshot of the bug.
Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: build on NeXTStep (PR#240)
Details: Jitterbug-Id: 240
Submitted-By: kragen@pobox.com (Kragen Sitaker)
Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST)
Version: None
OS: None
I'm building Python on NeXTStep; I've encountered three minor problems.
- importdl.c by default on NeXTStep allows linking with Objective-C
modules, which is cool. Unfortunately, properly supporting this
requires adding -ObjC to the cc command line in the Makefile.
- posixmodule.c doesn't #include anything that declares fsync() and
doesn't declare it itself, but tries to reference it. Adding a
declaration of fsync() fixes the problem.
- test_strftime and test_time fail.
test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: ''
I suspect this may be a platform bug. Here's some of the output,
which is 696 lines in full:
strftime test for Fri Mar 17 12:53:20 2000
Strftime test, platform: next3_3, Python version: 1.5.2
Conflict for %j (julian day (001-366)):
Expected 077, but got 076
Conflict for nonstandard '%c' format (near-asctime() format):
Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000
Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S):
Expected 03/17/00, but got Fri Mar 17 2000
Does not appear to support '%Z' format (time zone name)
Conflict for nonstandard '%D' format (mm/dd/yy):
Expected 03/17/00, but got ?
Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)):
Expected 17, but got ?
Conflict for nonstandard '%h' format (abbreviated month name):
Expected Mar, but got ?
Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)):
Expected 12, but got ?
Conflict for nonstandard '%n' format (newline character):
Expected
, but got ?
Conflict for nonstandard '%r' format (%I:%M:%S %p):
Expected 12:53:20 PM, but got ?
Conflict for nonstandard '%R' format (%H:%M):
Expected 12:53, but got ?
Conflict for nonstandard '%s' format (seconds since the Epoch in UCT):
Expected 953326400, but got ?
Conflict for nonstandard '%t' format (tab character):
Expected , but got ?
Conflict for nonstandard '%T' format (%H:%M:%S):
Expected 12:53:20, but got ?
Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth):
Expected 000, but got ?y
Conflict for %j (julian day (001-366)):
Expected 327, but got 326
Conflict for %W (week number of the year (Mon 1st)):
Expected 46, but got 47
Conflict for %j (julian day (001-366)):
Expected 328, but got 327
Conflict for %j (julian day (001-366)):
Expected 329, but got 328
Conflict for %j (julian day (001-366)):
Expected 330, but got 329
test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: ''
(and that was all of the output from test_time. Presumably this is
related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?)
I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch'
reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
'Command not found'.
I'm not trying to build a very sophisticated environment --- just the
defaults.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
====================================================================
Audit trail:
Mon Apr 03 18:40:11 2000 guido changed notes
Mon Apr 03 18:40:11 2000 guido moved from incoming to open
Follow-Ups:
Date: 2000-Jul-31 14:07
By: none
Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240)
Date: Fri, 24 Mar 2000 10:05:14 -0500
> I'm building Python on NeXTStep; I've encountered three minor problems.
>
> - importdl.c by default on NeXTStep allows linking with Objective-C
> modules, which is cool. Unfortunately, properly supporting this
> requires adding -ObjC to the cc command line in the Makefile.
> - posixmodule.c doesn't #include anything that declares fsync() and
> doesn't declare it itself, but tries to reference it. Adding a
> declaration of fsync() fixes the problem.
> - test_strftime and test_time fail.
> test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: ''
> I suspect this may be a platform bug. Here's some of the output,
> which is 696 lines in full:
[...]
> (and that was all of the output from test_time. Presumably this is
> related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?)
>
> I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch'
> reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
> 'Command not found'.
>
> I'm not trying to build a very sophisticated environment --- just the
> defaults.
Kragen,
Can you send us some patches? We don't have a NextStep system around
to test any of this, and your description of the problem doesn't help
me to create fixes that will certainly work for you.
There's probably not much you can do about the strftime problem --
just don't use time.strftime()! :-)
Please read python.org/patches for info on how to submit patches.
Thanks for contributing!
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------------------------------------------------
Date: 2000-Jul-31 14:07
By: none
Comment:
From: kragen@pobox.com (Kragen Sitaker)
Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240)
Date: Tue, 28 Mar 2000 12:46:18 -0500 (EST)
Guido writes:
> [Kragen wrote:]
> > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch'
> > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports
> > 'Command not found'.
It's NeXTStep 3.3.
> Can you send us some patches? We don't have a NextStep system around
> to test any of this, and your description of the problem doesn't help
> me to create fixes that will certainly work for you.
I can send a patch for importdl.c; the right thing to do for this would
be to modify the Makefile to change the flags passed to the compiler to
include -ObjC, but I don't know how to do that. My solution was to
change a #define in the source to turn off the ability to import
Objective-C modules, which is obviously far from optimal --- thus my
failure to include a patch for this in the first email.
In posixmodule.c, which needs fsync() declared, I'm not sure where to
declare it. I can certainly supply a patch that works for NeXTStep
3.3, but I don't understand the rat's-nest of #ifdefs there well enough
to be sure it won't break compilation on some other platform, or even
another version of NeXTStep --- thus my failure to include a patch for
this in the first email.
So I can send patches for both of these, but I am not sure if I should.
> Please read python.org/patches for info on how to submit patches.
Thanks.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
-------------------------------------------------------
Date: 2000-Jul-31 14:07
By: none
Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240)
Date: Tue, 28 Mar 2000 14:41:28 -0500
> It's NeXTStep 3.3.
>
> > Can you send us some patches? We don't have a NextStep system around
> > to test any of this, and your description of the problem doesn't help
> > me to create fixes that will certainly work for you.
>
> I can send a patch for importdl.c; the right thing to do for this would
> be to modify the Makefile to change the flags passed to the compiler to
> include -ObjC, but I don't know how to do that. My solution was to
> change a #define in the source to turn off the ability to import
> Objective-C modules, which is obviously far from optimal --- thus my
> failure to include a patch for this in the first email.
>
> In posixmodule.c, which needs fsync() declared, I'm not sure where to
> declare it. I can certainly supply a patch that works for NeXTStep
> 3.3, but I don't understand the rat's-nest of #ifdefs there well enough
> to be sure it won't break compilation on some other platform, or even
> another version of NeXTStep --- thus my failure to include a patch for
> this in the first email.
>
> So I can send patches for both of these, but I am not sure if I should.
Maybe we should just drop it? I don't think NextStep 3.3 has much
future or even much current use, does it? it's only supported for
historic reasons. If you get it to work, fine -- but I don't think
the general public would benefit much from adding NS 3.3 support...
Or am I wrong?
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110623&group_id=5470