Just for the record, here is a reply from the HP Porting center. It's
up to you to value it's content ...

--8<---
Subject: Re: HP Porting center: VCS git
Date: Thu, 17 Jan 2008 11:21:52 +0000 (GMT)
Message-Id: <200801171121.m0HBLqrc010962@linux01.cis>

I've had a look at the git 1.5.3.8 source code and there are several
HP-UX issues with it:

* Use of gcc-specific features. Doesn't seem to want to compile nicely
  with HP's ANSI C compiler.

* Failure of the configure/make to handle the lack of unsetenv() in
  pre-11.31 HP-UX releases. Bizarrely, it does handle the lack of setenv()
  and also has a compat/unsetenv.c for use by non-unsetenv()-capable OS'es,
  but then configure and config.mak.in completely fail to use a NO_UNSETENV
  variable like they should!

* Use of "-include config.mak.autogen" in the top-level Makefile doesn't
  seem to actually include that file. I had to remove the leading "-" to
  include it. Also had to stop "gmake clean" from deleting config.mak.autogen
  otherwise a second "gmake clean" would fail :-(

* Have to force use of /usr/local/bin/perl, otherwise it picks up /usr/bin/perl
  which the build system doesn't like.

* "gmake check" requires porting "sparse" at
  http://www.kernel.org/pub/software/devel/sparse/ which could be "fun".

I think not building with a non-gcc C compiler could be a showstopper for us -
our policy is to compile all packages (yes, even gcc itself) using HP's
ANSI C and C++ compilers unless it's literally impossible to do so (the
only package exception so far is "pdftk" and that's only because HP don't

At this moment in time, we just build using the default HP ANSI C/C++
bitness flags (i.e. none are used, rather than explicitly stating +DD32 or
+DD64). This defaults to 32-bit builds (e.g. ELF-32) on the 5 platforms we
port on - we have discussed moving to 64-bit builds with HP, but they want
us to stay on 32-bit for the time being. In an ideal world, it would be
useful to offer both 32-bit and 64-bit builds, but ...
[ message continues ]

Hi,


If that would be a bit more specific, we might very well be able to fix 

Didn't you provide them with a patch to Makefile making a run of 

That is strange.  The "-" in front means that the exit status of this 
command is ignored.  So it is no surprise that it fails when you remove 
the "-".  OTOH it is quite a surprise that it does not work when leaving 


You don't need to make "check".  You need to make "test".

Ciao,
Dscho

-

[ message continues ]

On Thu, 17 Jan 2008 16:58:36 +0000 (GMT), Johannes Schindelin



You mean this: ?
--8<---
--- Makefile.orig       2007-12-17 07:03:21 +0100
+++ Makefile    2007-12-17 18:04:37 +0100
@@ -401,6 +401,19 @@ EXTLIBS =
 # because maintaining the nesting to match is a pain.  If
 # we had "elif" things would have been much nicer...

+ifeq ($(uname_S),HP-UX)
+       # HP-UX
+       BASIC_LDFLAGS  += -L/usr/local/ssl/lib -L/usr/local/lib
+#      EXTLIBS        += -lc_r -lgcc
+       NO_HSTRERROR    = YesPlease
+       NO_ICONV        = YesPlease
+       NO_INET_NTOP    = YesPlease
+       NO_INET_PTON    = YesPlease
+       NO_UNSETENV     = YesPlease
+       NO_STRTOULL     = YesPlease
+       NO_STRTOUMAX    = YesPlease
+       NO_PREAD        = YesPlease
+endif
 ifeq ($(uname_S),Linux)
        NO_STRLCPY = YesPlease
 endif
-->8---

Note that this was on HP-UX 11.00/32. A 64bit env on 11.23/64 IPF will be
different.

I had no problem with my perl, as I specifically told that on the configure
line:



-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin.       http://qa.perl.org
http://mirrors.develooper.com/hpux/            http://www.test-smoke.org
                        http://www.goldmark.org/jeff/stupid-disclaimers/
-

[ message continues ]

Hi,


Almost:


I guess that my suggestion doesn't work... Your perl is not in 
/usr/local/bin...

Ciao,
Dscho

-

[ message continues ]

On Thu, 17 Jan 2008 18:14:00 +0000 (GMT), Johannes Schindelin


This was *my* CONF, not Richard's!

-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin.       http://qa.perl.org
http://mirrors.develooper.com/hpux/            http://www.test-smoke.org
                        http://www.goldmark.org/jeff/stupid-disclaimers/
-

[ message continues ]

Hi,


The point is: it should not be part of the Makefile if not most of the 
people have that setup.

Ciao,
Dscho

-

[ message continues ]

On Thu, 17 Jan 2008 18:24:29 +0000 (GMT), Johannes Schindelin

Ahh, right.

99.99% will have either one of these:

/opt/perl/bin/perl
/opt/perl32/bin/perl
/opt/perl64/bin/perl
/usr/local/bin/perl
/usr/bin/perl

I'd strongly suggest to filter /usr/contrib/bin/ out of whatever path is
used to find programs, as it might contain perl4

/pro/bin is only for me (and our customers). It is a safe place where we
will never interfere with whatever system perl is installed

-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x  on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin.       http://qa.perl.org
http://mirrors.develooper.com/hpux/            http://www.test-smoke.org
                        http://www.goldmark.org/jeff/stupid-disclaimers/
-

[ message continues ]

Is HP's ANSI C compiler C99 or C89? Git is sort of officially C89, but 
most developers use C99 compilers, so there's a bunch of C99-isms; seems 
to me like a slew of "inline" as a keyword and three C++/C99 comments.

If the compiler is supposed to be C99, the issues should be reported to HP 
and the gcc people, since "make CFLAGS=-std=c99" has no problem with git, 
suggesting that there's some issue with interpretation of the standard for 
one or the other.

	-Daniel
*This .sig left intentionally blank*
-

[ message continues ]

Update configure.ac (and config.mak.in) by adding test for unsetenv
(NO_UNSETENV).  Add comment about NO_UNSETENV to Makefile header, as
original commit 731043fd adding compat/unsetenv.c didn't do that.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>

I'm sorry for that. When I was checking which tests were missing from
configure.ac I have examined only Makefile header... and there was no
note about NO_UNSETENV there.

But the above comment I think also means that the uname base "guessage"
system in Makefile didn't catch that. You probably would want to modify
Makefile in that direction too; currently "guessage system" sets
NO_UNSETENV for and SunOS 5.8, SunOS 5.9, and you probably would want
to use it also for (older?) HP-UX.

 Makefile      |    2 ++
 config.mak.in |    1 +
 configure.ac  |    6 ++++++
 3 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 82e9cd6..f35e269 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,8 @@ all::
 #
 # Define NO_SETENV if you don't have setenv in the C library.
 #
+# Define NO_UNSETENV if you don't have unsetenv in the C library.
+#
 # Define NO_MKDTEMP if you don't have mkdtemp in the C library.
 #
 # Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
diff --git a/config.mak.in b/config.mak.in
index 15fb26c..40b14d9 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -40,6 +40,7 @@ NO_MEMMEM=@NO_MEMMEM@
 NO_STRLCPY=@NO_STRLCPY@
 NO_STRTOUMAX=@NO_STRTOUMAX@
 NO_SETENV=@NO_SETENV@
+NO_UNSETENV=@NO_UNSETENV@
 NO_MKDTEMP=@NO_MKDTEMP@
 NO_ICONV=@NO_ICONV@
 OLD_ICONV=@OLD_ICONV@
diff --git a/configure.ac b/configure.ac
index 6f641e3..af177fd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -356,6 +356,12 @@ AC_CHECK_FUNC(setenv,
 [NO_SETENV=YesPlease])
 AC_SUBST(NO_SETENV)
 #
+# Define NO_UNSETENV if you don't have unsetenv in the C library.
+AC_CHECK_FUNC(unsetenv,
+[NO_UNSETENV=],
+[NO_UNSETENV=YesPlease])
+AC_SUBST(NO_UNSETENV)
+#
 # Define NO_MKDTEMP if you ...
[ message continues ]