The C compiler that comes with HP/UX 11 has some shortcomings that prevent building Python 3.2.1 out of the box.  I am attaching patches here as I work through issues.

The first patch fixes namespace shortcomings when trying to use struct termios.

This patch works around the problem underlying issue 5999 by making sure the __STDC_VERSION__ macro is defined and has a value of at least 199901

You may the number of this issue in a comment of your patch.

Oops. You may *add* the number of this issue in a comment of your patch.

Workaround for compiler bug; HP/UX compiler refuses to past (implicitly char *) string constants with wide (wchar_t *) string constants.  This patch is also pasted to issue 12561 (which should be closed).

Note:  There is disagreement as to the best way to proceed on this issue.  Stinner (aka haypo) has a patch that should work with non ASCII character sets, and my patch will almost certainly not work in those cases.  YMMV.

Sorry - last comment should have been "compiler refuses to past*e*", not "past".

I think that getpath.patch is wrong (it's just a workaround hiding a real bug): see msg140422 of the issue #12561.

This patch just reduces compiler noise by explicitly casting pointers to void *.  I expect the Visual Studio C/C++ compiler suite also issued these warnings, too.

The HP/UX C compiler grumbles when a symbol that is declared static is later defined without the static storage class specifier.  The attached patch just adds the missing "static" keywords.

I'm adding the original listeners for issue 5999 to this one.

The fileutils.patch patch attached to this issue directly addresses what's wrong in issue 5999; I'd consider it closed, but as I didn't open it, and I'm not actually part of the python project, that's not my call to make.

From issue 12561 (which I will be closing):

Author: STINNER Victor (haypo) *  Date: 2011-07-15 15:36  
Use >L"" CONSTANT< to decode a byte string to a character string doesn't work with non-ASCII strings. _Py_char2wchar() should be used instead: see for example this fix, commit 5b6e13b6b473. 

This is in reference to getpath.patch.  I have no need to support internationalized versions of the constant strings my patch addresses, so Stinner's commit is overkill for me.

Minor note: we prefer unified diffs, and when possible, all related changes in one file.  See http://docs.python.org/devguide/

I can’t review the patches, as I don’t know C nor HP/UX.  I’m not sure why you opened this report instead of following on the other one :)

Update to getpath.patch (issue 12561) - this version uses _Py_char2wchar where possible.  Unfortunately, as lib_python is declared and defined statically, this can't be used in both cases where the HP/UX compiler has issues.

>The fileutils.patch patch attached to this issue directly addresses what's wrong in issue 5999; I'd consider it closed, ...

When an patch is committed that fixes that issue, say so there and I or someone will close it.

>From issue 12561 (which I will be closing):...
so Stinner's commit is overkill for me.

Issues sometimes expand beyond the original request. It is unclear to me whether Victor thinks that that issue is finished. If he thinks more should be done, then I think it should be left open.

Terry - I apologize for jumping the gun a bit, and let me be a bit more clear.  When I realized that the HP/UX compiler was going to have as many problems as it does compiling python 3, I decided it would be best to create a single issue for all of the compiler issues.  In retrospect, opening an issue for the single compiler bug discussed in issue 12561 was a mistake, and I had hoped to migrate the discussion of that issue here.

Please don't manage independent bugs in a single issue, even if they are related. The way this is done here will it make hard to track what exactly has been done, and what needs to be done.

As it stands, please combine all patches into a single one, and we won't commit anything until the entire patch passes.

Martin - I don't have time to manage your project's administrative requirements with respect to my fixes.  I'm providing them out of the hope they will be of use to others who need to build on HP/UX, but I don't really care if they make it into the main branch or not.

Here’s a unified diff.

Arg, I thought I removed a duplicate patch but it was actually an updated version.  Sorry about that; the link in the history at the bottom of this page still links to the file.  Updated unified diff attached.

Jim: Sorry if we reacted first with process remarks instead of thanking you for the patches and reviewing them.  We value contributions, and we try to be welcoming, but sometimes we forget what it’s like to enter this community.  Some things have become basic for us, like working with one unified diff instead of many context diffs, so we try to guide contributors so that their files can be easily read and fed to tools (such as code review or version control) and we can all move faster in the discussion leading to the commit.  This is not about project administration, merely common formats to make work easier for all parties involved (for example, for users generating one diff for a whole checkout is easier than generating and uploading one diff per file).

So, I hope that the diff I generated from yours will let people review it quickly, with no hurt feelings.

I believe this issue can be safely closed. It is a no-brainer to compile Python from master on HP-UX with aCC these days. It works for me at least.

Thank you for the update.  I think any problems with the current HP/UX compiler are best reported on a new issue.