FYI: Reply from HP-UX

FYI: Reply from HP-UX

[H.Merijn Brand]

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>
X-Mailer: ELM [version 2.5 PL7]

> I got git running on HP-UX 11.00, which still is our base for our Version
> Control System (VCS)s. Most of the changes I made were incorporated into
> the git mainline.  

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
have a compiler equivalent to gcj).

> Are there any plans to release a 64bit GIT build for 11.11 and/or 11.23
> on the porting center's? And if not (yet), can I hereby please request
> to consider that?  

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 technically it's too
difficult to automate (e.g. not just compiler flags, but also install
trees would have to be different between the two), so we can only easily
build one bitness and that's 32-bits for the moment.

HP-UX Archive Librarian,    E-mail queries: hpux@connect.org.uk
Connect Internet Solutions, Official HP-UX Archive WWW sites:
Liverpool,                  United Kingdom: http://hpux.connect.org.uk/
United Kingdom.             Netherlands:    http://hpux.its.tudelft.nl/
                            Canada:         http://hpux.ece.ualberta.ca/
                            United States:  http://hpux.cs.utah.edu/
-->8---

-- 
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/

Re: FYI: Reply from HP-UX

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, H.Merijn Brand wrote:

> > I got git running on HP-UX 11.00, which still is our base for our Version
> > Control System (VCS)s. Most of the changes I made were incorporated into
> > the git mainline.  
> 
> 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.

If that would be a bit more specific, we might very well be able to fix 
it.  After all, AFAIK we do support some non-gcc compilers.

> * 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!

Didn't you provide them with a patch to Makefile making a run of 
./configure unnecessary?

> * 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 :-(

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 
it alone...  What's the output?

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

This should be handled in your patch to Makefile IMHO.

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

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

Ciao,
Dscho

Re: FYI: Reply from HP-UX

[H.Merijn Brand]

On Thu, 17 Jan 2008 16:58:36 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:

> Hi,
> 
> On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> 
> > > I got git running on HP-UX 11.00, which still is our base for our Version
> > > Control System (VCS)s. Most of the changes I made were incorporated into
> > > the git mainline.  
> > 
> > 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.
> 
> If that would be a bit more specific, we might very well be able to fix 
> it.  After all, AFAIK we do support some non-gcc compilers.

Richard?

> > * 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!
> 
> Didn't you provide them with a patch to Makefile making a run of 
> ./configure unnecessary?

No, I didn't provide him (yet) with any additional information.

> > * 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 :-(
> 
> 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 
> it alone...  What's the output?
> 
> > * Have to force use of /usr/local/bin/perl, otherwise it picks up /usr/bin/perl
> >   which the build system doesn't like.
> 
> This should be handled in your patch to Makefile IMHO.

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:

$ ./configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl

> > * "gmake check" requires porting "sparse" at
> >   http://www.kernel.org/pub/software/devel/sparse/ which could be "fun".
> 
> You don't need to make "check".  You need to make "test".


-- 
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/

Re: FYI: Reply from HP-UX

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, H.Merijn Brand wrote:

> On Thu, 17 Jan 2008 16:58:36 +0000 (GMT), Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> 
> > On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> > 
> > > * Have to force use of /usr/local/bin/perl, otherwise it picks up 
> > > /usr/bin/perl which the build system doesn't like.
> > 
> > This should be handled in your patch to Makefile IMHO.
> 
> 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

Almost:

+	PERL_PATH = /usr/local/bin/perl

> -->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:
> 
> $ ./configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl

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

Ciao,
Dscho

Re: FYI: Reply from HP-UX

[H.Merijn Brand]

On Thu, 17 Jan 2008 18:14:00 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:

> Hi,
> 
> On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> 
> > On Thu, 17 Jan 2008 16:58:36 +0000 (GMT), Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > 
> > > On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> > > 
> > > > * Have to force use of /usr/local/bin/perl, otherwise it picks up 
> > > > /usr/bin/perl which the build system doesn't like.
> > > 
> > > This should be handled in your patch to Makefile IMHO.
> > 
> > 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
> 
> Almost:
> 
> +	PERL_PATH = /usr/local/bin/perl

Yep, should work

> > -->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:
> > 
> > $ ./configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl
> 
> I guess that my suggestion doesn't work... Your perl is not in 
> /usr/local/bin...

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/

Re: FYI: Reply from HP-UX

[Johannes Schindelin]

Hi,

On Thu, 17 Jan 2008, H.Merijn Brand wrote:

> On Thu, 17 Jan 2008 18:14:00 +0000 (GMT), Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> 
> > On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> > 
> > > $ ./configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl
> > 
> > I guess that my suggestion doesn't work... Your perl is not in 
> > /usr/local/bin...
> 
> This was *my* CONF, not Richard's!

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

Ciao,
Dscho

Re: FYI: Reply from HP-UX

[H.Merijn Brand]

On Thu, 17 Jan 2008 18:24:29 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:

> Hi,
> 
> On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> 
> > On Thu, 17 Jan 2008 18:14:00 +0000 (GMT), Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > 
> > > On Thu, 17 Jan 2008, H.Merijn Brand wrote:
> > > 
> > > > $ ./configure --prefix=/pro/local --disable-nls --without-iconv --with-perl=/pro/bin/perl
> > > 
> > > I guess that my suggestion doesn't work... Your perl is not in 
> > > /usr/local/bin...
> > 
> > This was *my* CONF, not Richard's!
> 
> The point is: it should not be part of the Makefile if not most of the 
> people have that setup.

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/

Re: FYI: Reply from HP-UX

[Daniel Barkalow]

On Thu, 17 Jan 2008, H.Merijn Brand wrote:

> 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
> have a compiler equivalent to gcj).

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*

[PATCH] autoconf: Add checking for unsetenv function

[Jakub Narebski]

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>
---
> * 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!

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 don't have mkdtemp in the C library.
 AC_CHECK_FUNC(mkdtemp,
 [NO_MKDTEMP=],
-- 
1.5.3.7