I'm forwarding this bug report to bug-gnulib from here:
https://bugs.gnu.org/50745
I don't have time to work on HP-UX 11.11 porting glitches right now, but
perhaps someone else does.--- Begin Message ---
See attached.
Dave
--
John David Anglin dave.ang...@bell.net
gnulib-test
. */
#define HAVE_SNPRINTF_RETVAL_C99 1
/* Define if the string produced by the snprintf function is always NUL
terminated. */
#define HAVE_SNPRINTF_TRUNCATION_C99 1
The HAVE_SNPRINTF_RETVAL define is definitely incorrect for HP-UX 11.11:
RETURN VALUE
Each function returns the number of
The machine which I used for HP-UX testing appears to not be accessible
any more. And for the last 3 years at least, I got the feeling that there
was no one building or using packages on HP-UX that rely on gnulib. So:
2020-05-10 Bruno Haible
doc: Mark HP-UX as unsupported
On HP-UX 11.31/ia64 with cc, I'm seeing this link error:
cc +DD64 -AC99 -D_HPUX_SOURCE -D_XOPEN_SOURCE=600 -g
-L/home/haible/prefix-hpux113ia64-64-cc/lib -o test-copysignf test-copysignf.o
libtests.a ../gllib/libgnu.a libtests.a
ld: Unsatisfied symbol "_copysignf" in file tes
On HP-UX 11.31 / ia64, I'm seeing these link errors:
cc +DD64 -AC99 -D_HPUX_SOURCE -D_XOPEN_SOURCE=600 -g
-L/home/haible/prefix-hpux113ia64-64-cc/lib -o test-pthread-mutex
test-pthread-mutex.o libtests.a ../gllib/libgnu.a libtests.a -lpthread
ld: Unsatisfied symbol "sem_trywait&quo
On HP-UX 11.31 I observe that the gnulib overrides in are not
activated. This is caused by the #if at the beginning of the file, which
contains a prevention against trouble on HP-UX 11.00.
The difference between HP-UX 11.00 and 11.31 here is that in 11.00 the
system's defines 'strto
On HP-UX 11.31 - both hppa and ia64 - I'm seeing test failures of test-wcstok.
A simple test program
=== foo.c =
#include
#include
#include
#include
int main ()
{
wchar_t string[] = L"hello world!";
wchar_t delim[] = L" ";
wcha
> On HP-UX 11, a testdir built with --with-c++-tests produces a number of
> errors
On HP-UX 11/ia64, in 32-bit mode, there is another set of errors:
source='../../gltests/test-stdio-c++.cc' object='test-stdio-c++.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../../
On HP-UX 11, a testdir built with --with-c++-tests produces a number of
errors about functions being undeclared. Which functions, depends on the
compiler options. The least number of such undeclared function errors
occur with the options -D_HPUX_SOURCE -D_XOPEN_SOURCE=600. In this case,
one error
On HP-UX 11.31/ia64 I'm seeing these errors:
DEPDIR=.deps depmode=hp2 /bin/sh ../../build-aux/depcomp \
cc +DD64 -AC99 -D_XOPEN_SOURCE=500 -DHAVE_CONFIG_H -I. -I../../gllib -I..
-DGNULIB_STRICT_CHECKING=1 -I/home/haible/prefix-hpux113ia64-64-cc/include -g
-c -o math.o ../../gllib/m
On 10/12/19 3:48 AM, Bruno Haible wrote:
Paul, if you understand it, the better.
I am not going to pursue this further, since HP-UX/hppa, while not being
end-of-life yet [1], has very little relevance for GNU.
I looked at the source and don't see how the problem could happen. I lack acces
The earlier commit
2019-09-15 Bruno Haible
intprops tests: Avoid build failure with HP-UX cc.
* tests/test-intprops.c: Disable a check that makes HP cc choke
with
"error 4018: Macro param too large after substitution - use -H
o
Hi,
With the regex module as of yesterday (before the
'Simplify and regularize regex use of ‘assert’' change) I see test
failures on HP-UX/hppa. Namely:
HP-UX cc on hppa, both 32-bit and 64-bit, even without any optimization:
(works with gcc, works with HP-UX cc on ia64)
$ ./
Building a test dir on HP-UX 11.31 with HP cc, I'm seeing this build failure:
cpp: "../../gltests/test-intprops.c", line 371: error 4018: Macro param too
large after substitution - use -H option.
gmake[3]: *** [test-intprops.o] Error 1
There are two ways to fix it:
(a) Ad
Florian Weimer wrote:
> > Oh well. Then it's even POSIX compliant. But HP-UX (and possibly
> > Windows) is the only platform where things are really like this -
> > otherwise we would have seen more platforms where the diffutils
> > 'new-file' test fai
* Bruno Haible:
> Oh well. Then it's even POSIX compliant. But HP-UX (and possibly
> Windows) is the only platform where things are really like this -
> otherwise we would have seen more platforms where the diffutils
> 'new-file' test fails.
glibc does this as well
Paul Eggert asks:
> > On HP-UX 11.31, however, the exec() call transforms a closed file
> > descriptor to a file descriptor that behaves identically to /dev/null,
> > regarding fstat and fcntl.
>
> Does this happen for all file decriptors, or only for file descriptors 0, 1
Bruno Haible wrote:
On HP-UX 11.31, however, the exec() call transforms a closed file
descriptor to a file descriptor that behaves identically to /dev/null,
regarding fstat and fcntl.
Does this happen for all file decriptors, or only for file descriptors 0, 1, and
2? If the latter, then HP-UX
issue
=
On most platforms, a file descriptor closed in a parent process is also
closed in the child process, and can be recognized by the fact that
fstat(fd) or fcntl(fd,F_GETFL) fail with error EBADF.
On HP-UX 11.31, however, the exec() call transforms a closed file
descriptor to a file
Hi Paul,
> Some HP-UX versions have a broken 'calloc' that could explain the bug. The
> broken 'calloc' returns memory that isn't properly zeroed. Can you
> investigate
> whether zeroing the calloc memory fixes the bug? Perhaps something like the
> att
Some HP-UX versions have a broken 'calloc' that could explain the bug. The
broken 'calloc' returns memory that isn't properly zeroed. Can you investigate
whether zeroing the calloc memory fixes the bug? Perhaps something like the
attached Gnulib patch? Thanks.
diff -
On Sun, Dec 16, 2018 at 11:34 AM Bruno Haible wrote:
> > So grep worked on HP-UX before because it was using the system regex code?
>
> I don't know. Maybe GNU grep never worked on HP-UX hppa? Or maybe it worked
> only when compiled by gcc? Or maybe the machine I
Hi Jim,
> So grep worked on HP-UX before because it was using the system regex code?
I don't know. Maybe GNU grep never worked on HP-UX hppa? Or maybe it worked
only when compiled by gcc? Or maybe the machine I have access to has a
particularly buggy cc compiler? Or maybe GNU grep worked
On Sun, Dec 16, 2018 at 9:16 AM Bruno Haible wrote:
>
> More on this:
> > On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken.
>
> The result in different gnulib versions is the same (HP-UX hppa, 32-bit):
>
More on this:
> On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken.
The result in different gnulib versions is the same (HP-UX hppa, 32-bit):
Version Result
-
20140101crash in regexec.c, line 1123
20150101crash
More on this:
> On HP-UX 11.31, hppa, in 32-bit mode, with cc, I observe the following
> test failures:
On HP-UX hppa (both 32-bit and 64-bit mode), regex and grep are broken.
On HP-UX ia64 (both 32-bit and 64-bit mode), regex and grep both work fine.
Bruno
On HP-UX 11.31, hppa, in 32-bit mode, with cc, I observe the following
test failures:
1) Among the gnulib tests (both from the 'grep' snapshot, as well as from
a gnulib testdir):
FAIL: test-regex
$ ./test-regex
Assertion failed: err == REG_ESPACE, file ../../lib/regexec.c, line
Testing a 'grep' snapshot on HP-UX 11.31 hppa, in 32-bit mode,
with cc (as I don't have a gcc on that machine), more precisely
CC="cc -AC99 -D_XOPEN_SOURCE=500", I get this compilation error:
CC obstack.o
cc: "../../lib/obstack.h", line 175: error
2018-10-11 Bruno Haible
getprogname: Add support for 32-bit programs on HP-UX.
* lib/getprogname.c (getprogname) [HP-UX]: If pstat_getproc fails,
try the similar functions 32-bit programs on 64-bit HP-UX.
diff --git a/lib/getprogname.c b/lib/getprogname.c
index 4f97df4
On HP-UX (hppa 64-bit), the test-xalloc-die.sh test fails:
*** - Thu Oct 11 15:47:41 2018
--- err2Thu Oct 11 15:55:06 2018
***
*** 1
! test-xalloc-die: memory exhausted
--- 1
! test-xalloc-di: memory exhausted
FAIL test-xalloc-die.sh (exit status: 1)
The reason is
On 24/04/18 20:08, Bruno Haible wrote:
Tom G. Christensen wrote:
This testcase uses SO_REUSEPORT which is not available everywhere.
From Solaris 9:
test-getsockname.c: In function 'open_server_socket':
test-getsockname.c:43:30: error: 'SO_REUSEPORT' undeclared (first use in
this function)
Tom G. Christensen wrote:
> This testcase uses SO_REUSEPORT which is not available everywhere.
>
> From Solaris 9:
> test-getsockname.c: In function 'open_server_socket':
> test-getsockname.c:43:30: error: 'SO_REUSEPORT' undeclared (first use in
> this function)
> setsockopt (s, SOL_SOCKET,
On 27/01/18 11:17, Bruno Haible wrote:
Here's what I'm committing for gnulib:
1) A test case for getsockname() that highlights the problem: It fails
on HP-UX in 64-bit mode (but succeeds in 32-bit mode).
This testcase uses SO_REUSEPORT which is not available everywhere.
From
On 64-bit HP-UX, socklen_t is defined as the 64-bit type 'size_t';
however the system calls getsockname() etc. read only the first 32 bits
from &addr_len. Because the endianness is BIG_ENDIAN, this reads as 0,
and thus these system calls don't fill in an address in the s
On HP-UX IA64 with this new shining compiler, I'm seeing this compilation
error:
---
cc +DD64 -AC99 -D_XOPEN_SOURCE=500 -DHAVE_CONFIG_H -I. -I../../src/gllib -I..
-g -c -o glthread/lock.o ../../src/gllib/glthread/l
#elif for HP-UX ia64 cc.
Thanks, I installed the attached.
From 92869ecabac197e41976d4c7785dd82d85165e0f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 19 Mar 2017 09:34:23 -0700
Subject: [PATCH] stdalign: tweak version# and test for HP-UX IA64
Problems reported by Bruno Haible in:
http
Hi Paul,
I spoke too soon when I wrote:
> I won't report a bug about this patch, because I don't have
> access to a HP-UX IA64 machine.
I have access to such a machine now.
1) About the version numbers:
$ cc -V
cc: HP C/aC++ B3910B A.06.27.03 [Nov 30 2012]
$ aCC -V
aCC: HP
Hi Paul,
> I'm inclined to guess that the 'aligned' attribute works on new-enough
> Itanium
> but not PA-RISC compilers.
Possibly. And I won't report a bug about this patch, because I don't have
access to a HP-UX IA64 machine.
But my previous report about a
2008 is "quite new"? Clocks must run slowly in the HP-UX world. :-)
>
> I guess the 'aligned' attribute works with some HP-UX cc compilers but not
> others. We know it does not work on your compiler (PA-RISC, __HP_cc==20).
> This circa 2013 email quoting Richa
Bruno Haible wrote:
This manual is for a quite new HP cc on Itanium (IA-64) servers.
I'm talking about an older HP cc on hppa.
2008 is "quite new"? Clocks must run slowly in the HP-UX world. :-)
I guess the 'aligned' attribute works with some HP-UX cc compilers bu
Hi Paul,
> That's strange, since Line 3 is taken almost verbatim from the HP-UX
> manual you mentioned.
This manual is for a quite new HP cc on Itanium (IA-64) servers.
I'm talking about an older HP cc on hppa.
> What happens if you compile with 'cc
> +std=gnu'
On 03/17/2017 02:12 PM, Bruno Haible wrote:
No, nothing like this works.
$ cat foo.c
int aa __attribute__ ((__aligned__ (8))) = 10;
int ab __attribute__ ((aligned (8))) = 10;
That's strange, since Line 3 is taken almost verbatim from the HP-UX
manual you mentioned. I looked for other p
Hi Paul,
> > CCLD ebrowse
> > cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array:
> > structs with FAMs cannot be members of other structs.
>
> This suggests that the HP-UX cc flexible array member bug is as follows: if a
> struct X
Bruno Haible wrote:
Emacs 25.1 cannot be built with this compiler.
Thanks for looking into this. Ouch. It looks like HP-UX cc has serious bugs in
its implementation of C99 flexible array members. I added this issue to
emacs/etc/PROBLEMS, and am suggesting GCC instead of HP-UX cc for people
tle bit more ugly than the previous code,
but it's still generic.
And with it, no change to _GL_INTEGER_WIDTH is needed. The problem in
# define WCHAR_WIDTH _GL_INTEGER_WIDTH (WCHAR_MIN, WCHAR_MAX)
was apparently due to the WCHAR_MIN macro, not the _GL_INTEGER_WIDTH macro.
2017-03-16 Bru
Hi Paul,
> Bruno Haible wrote:
> > Since I don't have access to a newer HP-UX cc compiler, I propose to just
> > disable this definition for HP-UX cc. This patch fixes the error.
>
> That sounds too drastic; I worry that it would break GNU Emacs, which relies
> on
ers-of-two widths, partly because it's more fun to be portable.
From a27d788de5ead5b5623d06f7eaa7fce89c5e64c0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 16 Mar 2017 01:04:22 -0700
Subject: [PATCH] limits-h: work around HP-UX 11.31 cc bug
Problem reported by Bruno Haible in:
http://
Bruno Haible wrote:
Since I don't have access to a newer HP-UX cc compiler, I propose to just
disable this definition for HP-UX cc. This patch fixes the error.
That sounds too drastic; I worry that it would break GNU Emacs, which relies on
having alignas.
Does Emacs 25.1 build with
Hi Paul,
With cc on HP-UX 11.31, test-stdint.c fails to compile:
cc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1
-I. -I. -I.. -I./.. -I../gllib -I./../gllib-g -c -o test-stdint.o
test-stdint.c
cc: "test-stdint.c", line 414: error 1511: Bit-field si
Hi Paul,
With cc on HP-UX 11.31, test-stdalign.c fails to compile:
cc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1
-I. -I. -I.. -I./.. -I../gllib -I./../gllib-g -c -o test-stdalign.o
test-stdalign.c
cc: "test-stdalign.c", line 65: error 1000:
Hi,
With cc on HP-UX 11.31, test-limits-h.c fails to compile, apparently
because LLONG_MIN, LLONG_MAX, ULLONG_MAX are not defined.
But /usr/include/limits.h defines LONG_LONG_MIN, LONG_LONG_MAX, ULONG_LONG_MAX.
So, here's the simple fix:
2017-03-14 Bruno Haible
limits-h: Ma
I'm adding support for HP-UX to the 'vma-iter' module.
It's useful for GNU clisp.
>From c1a21de2148bbc6cb3401e82ae1b75f0be077200 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Wed, 15 Mar 2017 22:07:56 +0100
Subject: [PATCH 1/2] vma-iter: Add support for HP-
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2014-01-20 Paul Eggert
+
+ stdalign: port to HP-UX compilers
+ * lib/stdalign.in.h (_Alignas): Use __attribute__ (__aligned__ (x))
+ if __HP_cc or __HP_aCC are nonzero.
+
2014-01-16 Paul Eggert
strtoimax: port to platforms lacking
On 10/31/2013 11:59 PM, H.Merijn Brand wrote:
> Any actions required for the failures on all other HP-UX versions?
I don't recall those, sorry. Did you mail them to bug-grep?
I don't see them here:
http://lists.gnu.org/archive/html/bug-grep/2013-10/threads.html
but perhap
On Thu, 31 Oct 2013 19:57:25 -0700, Jim Meyering
wrote:
> Thanks to both of you!
No problem. My pleasure.
Any actions required for the failures on all other HP-UX versions?
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.19 porting perl5
Thanks to both of you!
Thanks for the heads-up. All but one of those warnings
are false alarms. There is one that in theory could lead
to undefined behavior on some platforms (though not yours)
and I hope I have fixed it by installing the following gnulib
patch, which grep should pick up in due course.
>From e240f3332
expand to something like this:
inline void *xnmalloc (size_t n, size_t s) { return xmalloc (n * s); }
and C99 says that this should work. Evidently it's not working, though,
and it'd be helpful to know why (as things stand, my fix disables
inline functions entirely on HP-UX, which pro
Lloyd
To: bug-texi...@gnu.org
Subject: Re: HP-UX 11 build issues with texinfo 5.0
Here's some answers to the questions raised by my HP-UX 11 issues with
texinfo 5.0:
* The compiler I'm using is HP's optional ANSI C (located as /opt/ansic/bin/cc)
with a revision number of B.11.
y library
that tries to declare C99-style inline functions. For now, I've try to do
that in gnulib by installing the patch at the end of this message. But this
is fairly drastic, as it disables inline functions with HP-UX cc.
So it might be helpful to know more about the problem, to come up with a
l
Hello gnulib,
Richard Lloyd (cc'd) reported this to bug-texinfo:
* gnulib/lib/xalloc.h:
XALLOC_INLINE needed to be be defined as static (rather than extern
inline) to avoid multiple defintions of *alloc() routines. I just
put this in xalloc.h as follows (line 30):
#ifdef __hpux
--
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9f1b60f..fa5bda0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2013-02-08 Paul Eggert
+ extensions: port better to HP-UX
+ This is merged from git Autoconf.
+
Paul Eggert skribis:
> When deciding whether to define _XOPEN_SOURCE, inspect the
> preprocessor macro __hpux instead of the more-heavyweight
> operation of requiring AC_CANONICAL_HOST. Define _NETBSD_HOST on
> MINUX, for MINUX 3.
I think you meant “MINIX 3”. :-)
Ludo’.
/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2013-02-06 Paul Eggert
+ extensions: port better to MINUX 3, HP-UX, autoheader 2.62
+ Some of these changes are merged in from git Autoconf.
+ * m4/extensions.m4 (AC_USE_SYSTEM_EXTENSIONS):
+ When deciding whether to define
Voelker, Bernhard wrote:
> Bruno Haible wrote:
>
>> Hi Jim,
>>
>> > How about this?
>> >
>> > if (diff -u out out < /dev/null) > /dev/null 2>&1; then
>> >
>> > As usual, since your name is on it, I'll wait for an ACK
>> > before pushing it.
>>
>> Yes, that's just as good. Thanks!
>
> Do we
Bruno Haible wrote:
> Hi Jim,
>
> > How about this?
> >
> > if (diff -u out out < /dev/null) > /dev/null 2>&1; then
> >
> > As usual, since your name is on it, I'll wait for an ACK
> > before pushing it.
>
> Yes, that's just as good. Thanks!
Do we really need a subshell here?
This should
Hi Jim,
> How about this?
>
> if (diff -u out out < /dev/null) > /dev/null 2>&1; then
>
> As usual, since your name is on it, I'll wait for an ACK
> before pushing it.
Yes, that's just as good. Thanks!
Bruno
Bruno Haible wrote:
> Jim Meyering wrote:
...
> Thanks, this fixed the failures of this test on several platforms.
>
> But it introduced a minor problem: spurious output of the test.
>
> On AIX 6.1:
>
> ./test-init.sh[42]: There: not found.
> PASS: test-init.sh
>
> On Solaris 10/x86:
>
> ./test-in
Jim Meyering wrote:
> My test expected diff -u output.
> compare may generate diff -c output or even cmp output.
>
> This should fix it:
> +2012-01-05 Jim Meyering
> +
> + test-init.sh: avoid failure on HP-UX 11.00
> + * tests/test-init.sh: Skip "diff -u
Bruno Haible wrote:
>> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
> On HP-UX 11.00 with vendor cc:
>
> All coreutils tests pass. But 2 gnulib tests fail:
>
>
> FAIL: test-posixtm
> ==
...
>
> FAIL: test-init.sh
> =
remove the assumption. I don't know if this'll fix the
problem on HP-UX, but it does fix a portability bug.
>From 78f4bb60feed11a5241fec297d8250c1b11cc5b2 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 4 Jan 2012 16:04:38 -0800
Subject: [PATCH] test-posixtm: don't ass
> http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
On HP-UX 11.00 with vendor cc:
All coreutils tests pass. But 2 gnulib tests fail:
FAIL: test-posixtm
==
0101.00 return value mismatch: got 0, expected 1
12312359.59 return value mismatch: got 0, expecte
On HP-UX 11.00..11.31, with cc but not with gcc, the copysignl test fails:
test-copysignl.c:96: assertion failed
FAIL: test-copysignl
The reason is that the compiler implements the unary minus operator
incorrectly (!). Here is a workaround, limited to copysignl(), since we
cannot fix the
On HP-UX 11.00..11.11, the functions strtoimax and strtoumax exist only as
macros (defined in ), not as functions. I think that's not worth
correcting in gnulib, just documenting.
2011-09-01 Bruno Haible
strtoimax, strtoumax: Document problem on HP-UX 11.
* doc/
ow :-)
$ ack -l '^\s*#\s*include.*\.\/'
Exit 1
$ grep -r #include * | fgrep ./
Exit 1
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11
On 08/19/2011 06:23 AM, Giuseppe Scrivano wrote:
> it seems related to gnulib
What makes you think that? The error came when compiling gnulib
source code, true, but the diagnostic makes it look like there's
an '#include "./"' in config.h, or something like that, which
could well be non-gnulib rel
Hello,
The following bug report was sent to the wget mailing list, I am not
sure why it happens, it seems related to gnulib, has anyone an idea
about it?
I don't have access to any HP-UX box to test it by myself.
Thanks,
Giuseppe
> With HP-UX 11.00 and HP C-ANSI-C it doesn't
Bruno Haible wrote:
>> 1) To require AC_SYS_LARGEFILE, and a module dependency to 'largefile'.
>>This will make statvfs() use a 64-bit f_blocks on
>>glibc/Hurd, MacOS X >= 10.4, HP-UX, Solaris.
>
> Here's the first proposed patch. I verified that
> 1) To require AC_SYS_LARGEFILE, and a module dependency to 'largefile'.
>This will make statvfs() use a 64-bit f_blocks on
>glibc/Hurd, MacOS X >= 10.4, HP-UX, Solaris.
Here's the first proposed patch. I verified that
- on HP-UX 11.00 and 11.31, Solaris 7 and
On 06/18/2011 02:22 PM, Bruno Haible wrote:
> Hi,
>
> On HP-UX 11.31 I'm seeing this compilation failure:
>
> cc -Ae -D_XOPEN_SOURCE=500 -O -DHAVE_CONFIG_H -I. -DGNULIB_STRICT_CHECKING=1
> -I. -I. -I.. -I./.. -I../gllib -I./../gllib
> -I/home/haible/prefix-hpux113
Hi,
On HP-UX 11.31 I'm seeing this compilation failure:
cc -Ae -D_XOPEN_SOURCE=500 -O -DHAVE_CONFIG_H -I. -DGNULIB_STRICT_CHECKING=1
-I. -I. -I.. -I./.. -I../gllib -I./../gllib
-I/home/haible/prefix-hpux113-cc/include -g -c -o test-getcwd.o test-getcwd.c
cc: "test-getcwd.c",
--git a/ChangeLog b/ChangeLog
>> index 19a3dff..571df81 100644
>> --- a/ChangeLog
>> +++ b/ChangeLog
>> @@ -1,3 +1,11 @@
>> +2011-06-13 Paul Eggert
>> +
>> + ftoastr: use strtof only if HAVE_STRTOF
>> +This is needed on HP-UX 11.11 with GCC 4.2
+2011-06-13 Paul Eggert
> +
> + ftoastr: use strtof only if HAVE_STRTOF
> + This is needed on HP-UX 11.11 with GCC 4.24; see Bruno Haible's report
>
... there is a (very minor) typo here: "GCC 4.24" should be GCC "4.2.4"
> + <http://lists.gn
+1,11 @@
+2011-06-13 Paul Eggert
+
+ ftoastr: use strtof only if HAVE_STRTOF
+ This is needed on HP-UX 11.11 with GCC 4.24; see Bruno Haible's report
+ <http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00154.html>.
+ * lib/ftoastr.c (STRTOF) [LENGTH
Bruno Haible wrote:
> Hi Jim,
>
> By the way, you may want to announce this support of HP-UX >= 11.11 ACLs in
> the
> coreutils/NEWS file.
>
>> I prefer to split strings,
>
> I don't like splitting strings that contain simply long messages. If adding
>
Hi Paul,
Trying to compile coreutils-8.12 on HP-UX 11.11 with gcc 4.2.4, I get this
link error:
CCLD od
/usr/ccs/bin/ld: Unsatisfied symbols:
strtof (first referenced in ../lib/libcoreutils.a(ftoastr.o)) (code)
collect2: ld returned 1 exit status
gmake[3]: *** [od] Error 1
Hi Jim,
By the way, you may want to announce this support of HP-UX >= 11.11 ACLs in the
coreutils/NEWS file.
> I prefer to split strings,
I don't like splitting strings that contain simply long messages. If adding
a line break before the string does not help reaching the 80-colum
Bruno Haible wrote:
> On HP-UX 11.11 and newer, I'm seeing these test failures:
>
> file_has_acl("tmpfile0") returned no, expected yes
> FAIL: test-file-has-acl.sh
>
> FAIL: test-copy-acl.sh
> FAIL: test-copy-file.sh
>
> It turns out that the supp
On HP-UX 11.11 and newer, I'm seeing these test failures:
file_has_acl("tmpfile0") returned no, expected yes
FAIL: test-file-has-acl.sh
FAIL: test-copy-acl.sh
FAIL: test-copy-file.sh
It turns out that the support for HP-UX ACLs that I added on 2008-06-08
<http://lis
James Youngman wrote:
> > This is a security (mis)feature of HP-UX.
> > I noticed it with closeout-related tests a few years ago.
>
> I believe this anticipates an upcoming POSIX change:
> http://austingroupbugs.net/view.php?id=173
Thanks for this info. I'm updating
On Thu, Jun 9, 2011 at 11:01 AM, Jim Meyering wrote:
> Bruno Haible wrote:
>> Apparently, although fd 2 was closed in the parent process, it is open again
>> in the child process. This must happen in the exec* calls, since posix_spawn
>
> This is a security (mis)feature of
Bruno Haible wrote:
> On HP-UX 11.31, I'm seeing this test failure:
>
> test-spawn-pipe-child.c:99: assertion failed
> test-spawn-pipe.sh: iteration 4 failed
> test-spawn-pipe-child.c:99: assertion failed
> test-spawn-pipe.sh: iteration 5 failed
> test-spawn-
On Thu, Jun 9, 2011 at 11:44 AM, Bruno Haible wrote:
> On HP-UX 11.31, I'm seeing this test failure:
>
> test-spawn-pipe-child.c:99: assertion failed
> test-spawn-pipe.sh: iteration 4 failed
> test-spawn-pipe-child.c:99: assertion failed
> test-spawn-pipe.sh: iteration
On HP-UX 11.31, I'm seeing this test failure:
test-spawn-pipe-child.c:99: assertion failed
test-spawn-pipe.sh: iteration 4 failed
test-spawn-pipe-child.c:99: assertion failed
test-spawn-pipe.sh: iteration 5 failed
test-spawn-pipe-child.c:99: assertion failed
test-spawn-pi
On HP-UX 11, the ACL tests fail to compile:
cc: "test-sameacls.c", line 389: error 1594: The sizeof operator cannot be
applied to types with unknown size.
This fixes it.
2011-06-09 Bruno Haible
acl tests: Fix compilation error on HP-UX 11.
* tests/test-
On 06/08/2011 03:03 PM, Bruno Haible wrote:
> Similarly, on HP-UX 10.20 I observe this failure:
>
> test-rmdir.h:69: assertion failed
> FAIL: test-rmdir
>
> This fixes it. OK to apply?
Yep, go ahead.
>ASSERT (func (BASE "dir/.//") == -1);
> - ASSERT
);
>errno = 0;
>ASSERT (func (BASE "dir/.//") == -1);
> - ASSERT (errno == EINVAL || errno == EBUSY);
> + ASSERT (errno == EINVAL || errno == EBUSY || errno == EEXIST);
>ASSERT (func (BASE "dir") == 0);
>
>/* Test symlink behavior. Specifyin
Eric Blake wrote:
> The next-to-last command in this test has non-zero status. Even
> though 'exit 0' is supposed to ignore prior status, HP-UX /bin/sh
> favors the prior status if an exit trap is installed.
>
> * tests/test-perror.sh: Use Exit to avoid wrong exit stat
The next-to-last command in this test has non-zero status. Even
though 'exit 0' is supposed to ignore prior status, HP-UX /bin/sh
favors the prior status if an exit trap is installed.
* tests/test-perror.sh: Use Exit to avoid wrong exit status.
Signed-off-by: Eric Blake
---
This supports apps that need pointers to strtoimax and strtoumax,
and ports to HP-UX 11.00 64.bit, which has macros that expand to
nonexistent functions. See
<http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00241.html>
et seq.
* lib/inttypes.in.h (strtoimax, strtoumax): #undef
1 - 100 of 318 matches
Mail list logo
