Re: Python 1.2 on NeXTSTEP

Lele Gaifax (lele@nautilus.eclipse.it)
Tue, 18 Apr 95 12:01:42 +0200

Hi Guido, thanx for you answer but... ;-)

I extracted a new 1.2 release, made a configure and a make on it,
and finally "./python", followed by

> import os
> print os.listdir('.')

I'm attaching below part of its output, since I had to interrupt it
with a Ctrl-C:

gcc -posix -O -I./../Include -I.. -DHAVE_CONFIG_H
-DPYTHONPATH=\".:/usr/local/lib/python:/usr/local/lib/python/test:/usr/local/lib/python/\"
-c config.c
gcc -posix -O config.o libModules.a ../Python/libPython.a
../Objects/libObjects.a ../Parser/libParser.a -lm
-lm -o python
mv python ../python
lele@nautilus Python-1.2 $ ./python
Python 1.2 (Apr 18 1995) [GCC 2.6.3]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> print os.listdir ('.')
['\000\020\000\001.\000\035\000\000\000\000\030\000\001&\273\000\020\000\002..\000b\000\000\000(\000\000\014\367\000\024\000\004BUGS\000\000\000\000\000\000\000<\000\000\014\370\000\030\000\011ChangeLog\000}\000\000\000\000L\000\000\031\256\000\024\000\007Contrib\000\000\000\000\\\000\001\031\323\000\024\000\004Demo\000\004\000\000\000\000\000h\000\002eH\000\020\000\003Doc\000\000\000\000x\000\000\203\221\000\024\000\007Grammar\000\000\000\000\210\000\000%\364\000\024\000\007Include\000\000\000\000\224\000\001\220\251\000\020\000\003Lib\000\000\000\000\250\000\000\014\371\000\030\000\013Makefile.in\000\000\000\000\270\000\002\302\373\000\024\000\004Misc\000\000\000i\000\000\000\310\000\002\334-\000\024\000\007Modules\000\000\000\000\330\000\002\350E\000\024\000\007Objects\000\000\000\000\350\000\002\357\005\000\024\000\006Parser\000T\000\000\000\370\000\002\364\252\000\024\000\006Python\000\000\000\000\001\010\000\000\014\372\000\024\000\006README\000s\000\000\001\030\000\00!
0\014\373\000\024\000\004TODO\000T_A\000\000\001(\000\000\266`\000\024\000\005Tools\000\010\000\000\000\001<\000\000\014\374\000\030\000\012acconfig.h\000\001\000\000\001P\000\000\014\375\000\030\000\013config.h.in\000\000\000\001d\000\000\014\376\000\030\000\011configure\000\007\000\000\000\001|\000\000\014\377\000\034\000\014configure.in\000\000S_\000\000\001\220\000\000\015\010\000\030\000\012config.log\000S\000\000\001\244\000\000\015\015\000\030\000\010Makefile\000\000\000S\000\000\001\274\000\000\015\013\000\034\000\014config.cache\000ISF\000\000\001\324\000\000\015\014\000\034\000\015config.status\000CK\000\000\001\350\000\000\015\011\000\030\000\010config.h\000GID\000\000\004\000\000\002\334\204\000\024\000\006python\000ISVTXs......

This on a NeXTStation Color, running the 3.3 user/3.2 developer.

Python built with the patches I sent you works ok:

lele@nautilus Python-1.2 $ cd ../Python-1.2-NeXT/
lele@nautilus Python-1.2-NeXT $ ./python
Python 1.2 (Apr 15 1995) [GCC 2.6.3]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> print os.listdir ('.')
['.', '..', 'BUGS', 'ChangeLog', 'Contrib', 'Demo', 'Doc',
'Grammar', 'Include', 'Lib', 'Makefile.in', 'Misc', 'Modules',
'Objects', 'Parser', 'Python', 'README', 'TODO', 'Tools',
'acconfig.h', 'config.h.in', 'configure', 'configure.in',
'configure.orig', 'config.log', 'Makefile', 'config.cache',
'config.status', 'config.h', 'python']

I think we should eventually focus on correcting Python (and in my
opinion it's not broken) rather than relying on the supposed POSIX
compatibility library available on NS. Maybe NS Developer 3.3 is
better on thin than 3.2, and eventually 4.0 better than better, but
I really don't know how many of us can afford the new developer
package cost... What is exactly that forced you to add '-posix' flag
to gcc only on the NeXT?

> Still, I think that adding that list of prototypes to posixmodule.c
> (which is very similar to a list that's there already) is bad taste
> too.

Yes, I agree with you. The best solution on the NeXT is to include
just <libc.h>, that contains all those declaration that aren't in
other headers. autoconf should check for it, since I think other C
implementation use a similiar file.

Another point: configure.in uses "uname" to build the name of the
subdirectory of library that contains system specific code. This is
bad, since "uname" is not available everywhere... This is the result
on NeXTSTEP:
...
checking for uid_t in sys/types.h... yes
checking MACHDEP... ./configure: uname: not found
./configure: uname: not found

./configure: uname: not found
./configure: uname: not found
checking SO... .so
...

Did you consider using something similar to the config.guess
distruibuited with GNU Emacs, GCC, and many other GNU packages?

well, thanx