threads / discuss / 11656

FYI: Reply from HP-UX

Subject: FYI: Reply from HP-UX

## tl;dr

9 messages between Jan 17, 2008 and Jan 18, 2008.

replies: 8people: 4as markdown or json

H.Merijn Brand· Jan 17, 2008, 13:11 UTC · lore

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/
Johannes Schindelin· Jan 17, 2008, 16:58 UTC · re: H.Merijn Brand · lore

Re: FYI: Reply from HP-UX

Hi,
On Thu, 17 Jan 2008, H.Merijn Brand wrote:
Show 9 quoted lines
> > 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.

Show 5 quoted lines
> * 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

H.Merijn Brand· Jan 17, 2008, 17:55 UTC · re: Johannes Schindelin · lore

Re: FYI: Reply from HP-UX

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

Show 16 quoted lines
> 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?
Show 8 quoted lines
> > * 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.
Show 14 quoted lines
> > * 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/
Johannes Schindelin· Jan 17, 2008, 18:14 UTC · re: H.Merijn Brand · lore

Re: FYI: Reply from HP-UX

Hi,
On Thu, 17 Jan 2008, H.Merijn Brand wrote:
Show 31 quoted lines
> 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
Show 9 quoted lines
> -->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

H.Merijn Brand· Jan 17, 2008, 18:21 UTC · re: Johannes Schindelin · lore

Re: FYI: Reply from HP-UX

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

Show 39 quoted lines
> 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
Show 12 quoted lines
> > -->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/
Johannes Schindelin· Jan 17, 2008, 18:24 UTC · re: H.Merijn Brand · lore

Re: FYI: Reply from HP-UX

Hi,
On Thu, 17 Jan 2008, H.Merijn Brand wrote:
Show 11 quoted lines
> 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

H.Merijn Brand· Jan 17, 2008, 18:29 UTC · re: Johannes Schindelin · lore

Re: FYI: Reply from HP-UX

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

Show 18 quoted lines
> 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/
Daniel Barkalow· Jan 17, 2008, 21:17 UTC · re: H.Merijn Brand · lore

Re: FYI: Reply from HP-UX

On Thu, 17 Jan 2008, H.Merijn Brand wrote:
Show 5 quoted lines
> 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*
Jakub Narebski· Jan 18, 2008, 01:03 UTC · re: H.Merijn Brand · lore

[PATCH] autoconf: Add checking for unsetenv function

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>
---
Show 5 quoted lines
> * 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

← back to recent threads