configure problems porting to Tru64
I've been trying to build with the current CVS on Tru64 today. This is Tru64 Unix 5.1a with Compaq C++ 6.5. I've run into a bunch of problems with posixmodule.c (not surprise there), but I don't know what the right strategy for fixing them is. Here is a conflicting set of problems: fchdir() is only defined if _XOPEN_SOURCE_EXTENDED is defined. setpgrp() takes no arguments if _XOPEN_SOURCE_EXTENDED is defined, but two arguments if it is not. I found the fchdir() problem first and though the solution would be to change this bit of code in Python.h: /* Forcing SUSv2 compatibility still produces problems on some platforms, True64 and SGI IRIX being two of them, so for now the define is switched off. */ #if 0 #ifndef _XOPEN_SOURCE # define _XOPEN_SOURCE 500 #endif #endif And change "#if 0" to "#if __digital__", but that causes the setpgrp() problem to appear. It seems that configure has a test for whether setpgrp() takes arguments, but configure runs its test without defining _XOPEN_SOURCE. (I'll also note that configure.in has a rather complex test for this, when it appears that autoconf has a builtin AC_FUNC_SETPGRP. Anyone know why we don't use this?) How should we actually fix this problem? It seems to me that the right solution is to define _XOPEN_SOURCE in Tru64 and somehow guarantee that configure runs its tests with that defined, too. How would we achieve that? Jeremy
(I'll also note that configure.in has a rather complex test for this, when it appears that autoconf has a builtin AC_FUNC_SETPGRP. Anyone know why we don't use this?)
I'll bet AC_FUNC_SETPGRP didn't exist in the autoconf version we were using when we wrote that test. Feel free to fix it. BTW, the snake farm build for AIX-2-000000042E00-hal now fails like this: ../python/dist/src/Modules/posixmodule.c: In function `posix_fdatasync': ../python/dist/src/Modules/posixmodule.c:902: `fdatasync' undeclared (first use this function) ../python/dist/src/Modules/posixmodule.c:902: (Each undeclared identifier is reported only once ../python/dist/src/Modules/posixmodule.c:902: for each function it appears in.) --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> BTW, the snake farm build for AIX-2-000000042E00-hal now fails GvR> like this: GvR> ../python/dist/src/Modules/posixmodule.c: In function GvR> `posix_fdatasync': GvR> ../python/dist/src/Modules/posixmodule.c:902: `fdatasync' GvR> undeclared (first use this function) GvR> ../python/dist/src/Modules/posixmodule.c:902: (Each undeclared GvR> identifier is reported only once GvR> ../python/dist/src/Modules/posixmodule.c:902: for each function GvR> it appears in.) (I already mentioned this to Guido, but) This problem has been occuring on AIX for a while. It's unrelated to staticforward. So we've now confirmed that staticforward is unneeded on AIX and Tru64. Perhaps MAL would like to find an SCO ODT compiler to try it out with. Jeremy
Jeremy Hylton <jeremy@alum.mit.edu> writes:
(I'll also note that configure.in has a rather complex test for this, when it appears that autoconf has a builtin AC_FUNC_SETPGRP. Anyone know why we don't use this?)
That test was introduced in configure.in 1.9, on 1994/11/03. It might well be that autoconf did not support that test at that time.
How should we actually fix this problem? It seems to me that the right solution is to define _XOPEN_SOURCE in Tru64 and somehow guarantee that configure runs its tests with that defined, too. How would we achieve that?
I think it is generally the right thing to define _XOPEN_SOURCE on Unix, providing a negative list of systems that cannot support this setting (or preferably solving whatever problems remain). I'd put an (unconditional) AC_DEFINE into configure.in early on; it *should* go into confdefs.h as configure proceeds, and thus be active when other tests are performed. Regards, Martin
Thanks. This suggestions gets the compile to succeed on Tru64 and does not harm on Linux. I'll check it in and see what happens on the snake farm tonight. There's one more problem with Tru64: cc -o python Modules/python.o libpython2.3.a -lrt -lpthread -lm -threads ld: Unresolved: makedev It looks like Tru64 doesn't have a makedev(). You added the patch that included this a while back. Do you have any idea what we should do on Tru64? Jeremy
Jeremy Hylton wrote:
There's one more problem with Tru64:
cc -o python Modules/python.o libpython2.3.a -lrt -lpthread -lm -threads ld: Unresolved: makedev
It looks like Tru64 doesn't have a makedev(). You added the patch that included this a while back. Do you have any idea what we should do on Tru64?
jeremy@alum.mit.edu (Jeremy Hylton) writes:
It looks like Tru64 doesn't have a makedev(). You added the patch that included this a while back. Do you have any idea what we should do on Tru64?
Neal says you need to define _OSF_SOURCE, but it would better if we could do without. If not, we should both define _OSF_SOURCE (perhaps only on OSF), and add an autoconf test for makedev. Regards, Martin
"Martin v. Loewis" wrote:
jeremy@alum.mit.edu (Jeremy Hylton) writes:
It looks like Tru64 doesn't have a makedev(). You added the patch that included this a while back. Do you have any idea what we should do on Tru64?
Neal says you need to define _OSF_SOURCE, but it would better if we could do without. If not, we should both define _OSF_SOURCE (perhaps only on OSF), and add an autoconf test for makedev.
I agree with Martin. It would be best to only define _OSF_SOURCE if absolutely necessary and use autoconf. Neal
participants (5)
-
Guido van Rossum -
Jeremy Hylton -
jeremy＠alum.mit.edu
-
martin＠v.loewis.de -
Neal Norwitz