Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-44583: Fix build for OSF1/Tru64. #27063

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

jaykrell
Copy link

@jaykrell jaykrell commented Jul 8, 2021

This enables building with gcc4 (4.7.4) on OSF1/Tru64.
gcc3 (3.4.6) and native cc are a bit different, and might be handled later.

  • _XOPEN_SOURCE_EXTENDED both hides and reveals content.
    There is no good answer.
    The system headers define it by default.
    Undefine it to avoid warnings about repeated defines.
    Duplicate a few lines of content that are under ifndef _XOPEN_SOURCE_EXTENDED
  • Duplicate a few other troublesome lines, i.e. due to ifdef _BSD
  • Possible duplication summary: round, finite, copysign, NSIG, setenv, unsetenv
  • OSF1 appears to have no monotic timer; fake it badly with realtime
    This is probably the worst part.
  • unsetenv is broken, returns void, not int
    configure fails to detect this, because the
    prototype is under ifdef _BSD and the program compiles without warning or error;
    unprototyped functions are assumed to return int, after all
  • wait4 always takes union wait; cast
  • printf C99 macros are missing with gcc
  • sendfile is implemented and documented, but not declared and does not match other systems; skip it
  • plock is documented and probably implemented, but not declared; declare it
  • cast away const in initgroups call (safe for all systems)

The fixes are a bit spread out between configure.ac, pyconfig.h.in
and new file pyportosf.h. It may be preferable to consolidate, esp. in configure.ac.

Fwiw I got python2 running also.

https://bugs.python.org/issue44583

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@jaykrell

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@jaykrell jaykrell force-pushed the osf branch 4 times, most recently from 3ac8e47 to d1e2928 Compare July 8, 2021 09:13
@jaykrell jaykrell changed the title [draft] bpo-44583: A few fixes for OSF1/Tru64. [draft] bpo-44583: ] Fix build for OSF1/Tru64. Jul 8, 2021
@jaykrell jaykrell changed the title [draft] bpo-44583: ] Fix build for OSF1/Tru64. [draft] bpo-44583: Fix build for OSF1/Tru64. Jul 8, 2021
@jaykrell jaykrell force-pushed the osf branch 5 times, most recently from e2101da to de9293c Compare July 8, 2021 10:34
@jaykrell
Copy link
Author

jaykrell commented Jul 8, 2021

install succeeds a lot:

bash-5.1$ pwd
/usr/users/jay/o/py3

bash-5.1$ head *log
  $ /usr/users/jay/s/cpython/configure -prefix=/usr/users/jay/i/1 -disable-nls -verbose

bash-5.1$  /usr/users/jay/i/1/bin/python3.11

Python 3.11.0a0 (heads/osf-dirty:de9293c91c6, Jul  8 2021, 06:52:00) [GCC 4.7.4] on osf1V5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> u = os.uname()
>>> u[0]
'OSF1'
>>> u[2]
'V5.1'
>>> u[4]
'alpha'
>>> ^D
bash-5.1$ uname -srm
OSF1 V5.1 alpha

but install eventually fails:

Traceback (most recent call last):
  File "/usr/users/jay/s/cpython/Lib/subprocess.py", line 69, in <module>
    import msvcrt
    ^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'msvcrt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/users/jay/s/cpython/Lib/runpy.py", line 187, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/users/jay/s/cpython/Lib/runpy.py", line 146, in _get_module_details
    return _get_module_details(pkg_main_name, error)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/users/jay/s/cpython/Lib/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
    ^^^^^^^^^^^^^^^^^^^^
  File "/usr/users/jay/s/cpython/Lib/ensurepip/__init__.py", line 4, in <module>
    import subprocess
    ^^^^^^^^^^^^^^^^^
  File "/usr/users/jay/s/cpython/Lib/subprocess.py", line 74, in <module>
    import _posixsubprocess
    ^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named '_posix

@jaykrell jaykrell marked this pull request as ready for review July 8, 2021 12:01
@jaykrell jaykrell changed the title [draft] bpo-44583: Fix build for OSF1/Tru64. bpo-44583: Fix build for OSF1/Tru64. Jul 8, 2021
@jaykrell jaykrell force-pushed the osf branch 4 times, most recently from b245e0a to 8f9fc33 Compare July 8, 2021 12:21
This is meant to enable compiling with gcc4 (4.7.4).
gcc3 (3.4.6) and native cc are a bit different, and might be handled later.

 - _XOPEN_SOURCE_EXTENDED both hides and reveals content.
   There is no good answer.
   The system headers define it by default.
   Undefine it to avoid warnings about repeated defines (having included
     sys/types to get gid_t to reproduce some if'ed out system header content).
   Duplicate a few lines of content that are under ifndef _XOPEN_SOURCE_EXTENDED.
 - Duplicate a few other troublesome lines, i.e. due to ifdef _BSD.
 - Possible duplication summary: round, finite, copysign, NSIG, setenv, unsetenv.
 - OSF1 appears to have no monotic timer; fake it badly with realtime
   This is probably the worst part, actual semantic degradation.
 - unsetenv is broken, returns void, not int
   configure fails to detect this, because the
   prototype is under ifdef _BSD and the program compiles without warning;
   unprototyped functions are assumed to return int, after all
 - wait4 always takes union wait* even if int* is used elsewhere; cast
 - printf C99 macros are missing with gcc
 - sendfile is implemented and documented, but does not match other systems; skip it
 - plock is documented and probably implemented, but not declared; declare it
 - cast away const in initgroups call (safe for all systems)
 - Specifying visibilty on OSF/1 warns each time; don't do it.
The fixes are a bit spread out between configure.ac, pyconfig.h.in
and new file pyportosf.h. It may be preferable to consolidate, esp. in configure.ac.
// Native cc support is hypothetical. gcc4 is being used.
#define __STDC_CONSTANT_MACROS 1
#define __STDC_LIMIT_MACROS 1
#define __STDC_FORMAT_MACROS 1
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are ok for all systems. Some others even require at least one of them.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double copysign(double, double); // /usr/include/math.h ifndef _XOPEN_SOURCE_EXTENDED
int initgroups(char*, gid_t); // /usr/include/grp.h ifndef _XOPEN_SOURCE_EXTENDED
int plock(int); // documented but not declared anywhere
#define HAVE_BROKEN_UNSETENV 1 // unsetenv returns void, not int; configure fails because ifdef _BSD
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the PR is mostly ok, I can try to fix configure.ac instead.
i.e. it could say:

#if defined(__osf__) && !defined(_BSD)
#define _BSD
#endif

typedef union wait WAIT4_TYPE;
#else
typedef WAIT_TYPE WAIT4_TYPE;
#endif
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok, but if reviewers prefer, I could probably autoconf this.

/* Define to 1 if you have the `sendfile' function. */
#undef HAVE_SENDFILE
#endif
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok, but if reviewers prefer, I could probably kinda autoconf it.

In particular, the check for sendfile would move out of the list of funcs, and into an individual call, that is conditional on not being OSF.
And/or we could confirm there is a declaration and what it is "like".
That would likely cleanup other systems.
Assuming the declaration is not difficult to attain.

I want to at least test the waters to see if anything is ok for OSF1, and if so, can refine it in this PR or a followup.


#endif // __GNUC__

#define CLOCK_MONOTONIC CLOCK_REALTIME // no known monotonic time source; fake it poorly for py_get_monotonic_clock
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be based on ifndef CLOCK_MONOTIC.
Here though I have minimized includes, and OSF will surely never change.
Perhaps autoconf?
Ideally still, to find a monotonic time source.

// incorrect system definition: "X"
#define PRIX64 "lX"
#define PRIXPTR "lX"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These probably be "approximately" autoconfed.
That is, if we have the types int64_t, compare their size to int, long, long long, and whatever we find matches, use their strings.

Something like this:
https://github.com/mono/mono/blob/e44d84d10a0a6bfe8376cec30582c5c93fd3a92f/configure.ac#L5340

@ronaldoussoren
Copy link
Contributor

Support for OSF1 was removed in Python 3.3 (see https://www.python.org/dev/peps/pep-0011/#unsupporting-platforms).

I expect that there will be little interest amongst the core developers for reintroducing support because OSF1 is an ancient operating system that is long out of support.

@jaykrell
Copy link
Author

jaykrell commented Jul 9, 2021

Yeah, I found that eventually.
It does take exceedingly little code: this PR. Hopefully it is ok.
I can likely move some to configure.ac as well, if that helps.
I think the install errors were just that gcc was no longer in $PATH. I will check.

@Ringdingcoder
Copy link

Support for OSF1 was removed in Python 3.3 (see https://www.python.org/dev/peps/pep-0011/#unsupporting-platforms).

I expect that there will be little interest amongst the core developers for reintroducing support because OSF1 is an ancient operating system that is long out of support.

FWIW, because I cannot see it referenced here. This is the commit that removed it: 736e7fc

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Aug 19, 2021
@github-actions github-actions bot removed the stale Stale PR or inactive for long period of time. label Aug 10, 2022
@jaykrell jaykrell mannequin mentioned this pull request Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants