When compiling on HP-UX with the native cc compiler, the following compilation error occurs in pytime.c

        cc -Ae -c  -O  -O     -I. -I./Include    -DPy_BUILD_CORE -o Python/pytime.o Python/pytime.c
"Python/pytime.c", line 723: error #2020: identifier "CLOCK_MONOTONIC" is
          undefined
      const clockid_t clk_id = CLOCK_MONOTONIC;
                               ^

1 error detected in the compilation of "Python/pytime.c".
*** Error exit code 2

Stop.


HP-UX does not support the CLOCK_MONOTONIC state.

> HP-UX does not support the CLOCK_MONOTONIC state.

I'm sorry but CPython requires a monotonic clock since CPython 3.5.

According to https://bugreports.qt.io/browse/QTBUG-22301 HP-UX < 11.3 and Solaris 9 don't support monotonic clock.

It seems like gethrtime() is the right function to be used on HP-UX.
https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/gethrtime.3C.html

"gethrtime() is measured from an unspecified starting point and is not subject to time server and administrator changes"
src: http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking#gethrtimenbsp

> It seems like gethrtime() is the right function to be used on HP-UX.
> https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/gethrtime.3C.html

Thanks, I'll work on getting a patch that leverages gethrtime() tested and submitted for review.

I'm quite sure that once I wrote a patch using gethrtime() for Solaris, but then I saw that it's the same clock than clock_gettime(CLOCK_MONOTONIC), so I removed gethrtime() to simplify the code.

See also my PEP 418, which mentions gethrtime() by the way:
https://www.python.org/dev/peps/pep-0418/#solaris-gethrtime

I submitted a pull request for a possible fix for this issue but haven't received any feedback yet. Is there any additional information needed from me?

New changeset c90e96015085784df86632b26059b19c80cbfc97 by Victor Stinner (haney) in branch 'master':
bpo-30183: Fixes HP-UX cc compilation error in pytime.c (#1351)
https://github.com/python/cpython/commit/c90e96015085784df86632b26059b19c80cbfc97

I'd love to have this fix backported to 3.5 and 3.6.  It seems trivial to do, and I'd be happy to do it myself.

> I'd love to have this fix backported to 3.5 and 3.6.  It seems trivial to do, and I'd be happy to do it myself.

Go ahead :-)

Can someone please give the list of failing tests of the Python master branch on HP-UX?

I am having trouble getting things build still.  The problem is that the build is using a naked "ld" to link, and it is picking 32-bit mode by default in my 64-bit acc build. (Itanium)

IMO the problem is configure.ac:2467 which should look more like the gcc section.  I can produce a patch, and perhaps you can walk me though the submission process.

@David Haney: Can you please give the list of tests which fail on HP-UX? I would like to have an idea of the status of the HP-UX support.

I've attached the test output summary from a recent build.

Oh ok, a lot of tests fail on HP-UX. We are far from supporting HP-UX.

331 tests OK.
41 tests failed:
    test_asyncio test_asyncore test_c_locale_coercion test_calendar
    test_cmd_line test_cmd_line_script test_datetime test_distutils
    test_email test_faulthandler test_fileio test_httpservers
    test_imaplib test_imp test_import test_io test_logging
    test_macpath test_mailbox test_mmap test_multiprocessing_fork
    test_multiprocessing_forkserver test_multiprocessing_main_handling
    test_multiprocessing_spawn test_ntpath test_openpty test_os
    test_posix test_posixpath test_pty test_re test_signal
    test_strftime test_strptime test_subprocess test_time test_tools
    test_unicode test_unicode_file test_xmlrpc test_zipimport

I have applied the patch to 3.6.6 from the source tarball and I was able to proceed with the compilation.

I would take the failed tests as blocker. Try to solve them later.

Can this be closed?

Yes, I close the issue.

stage: patch review -> resolved

messages: + msg297893