Re: socket functions on HP-NonStop

Joachim Schmitz wrote: > This doesn't seem to be sufficient, I still (or now? Not sure) get errors for > inet_ntop() and accept(): > > argument of type "socklen_t *" is incompatible with parameter of > type "size_t *" Can you give the complete error message, please? (Just to b

Re: socket functions on HP-NonStop

Joachim Schmitz wrote: > This seems to be indeed new and due to the new "#include " which > doesn't agree with gnulib's arpa/inet.h > > source='test-getaddrinfo.c' object='test-getaddrinfo.o' libtool=no > DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp cc -DHAVE_CONFIG_H > -I. -DGNU

RE: socket functions on HP-NonStop

Hi Bruno This seems to be indeed new and due to the new "#include " which doesn't agree with gnulib's arpa/inet.h source='test-getaddrinfo.c' object='test-getaddrinfo.o' libtool=no DEPDIR=.deps depmode=none /bin/sh ./../build-aux/depcomp cc -DHAVE_CONFIG_H -I. -DGNULIB_STRICT_CHECKING=1 -I

Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

[Adding libtool to the CC: list, since Bob indicates there are libtool and autoconf implications as well. The thread starts at .] On 12/26/2010 09:51 AM, Bruno Haible wrote: > So, when libposix becomes reality, it may be compile

times test warnings

Hi Simon, On OSF/1 5.1, with "gcc -Wall", I'm seeing these warnings: test-times.c:63: warning: format '%ld' expects type 'long int', but argument 2 has type 'clock_t' test-times.c:64: warning: format '%ld' expects type 'long int', but argument 2 has type 'clock_t' test-times.c:65: warning: form

linkat, LINK_FOLLOWS_SYMLINKS, and Solaris

Hi Eric, In the linkat implementation (lib/linkat.c), there is the assumption that the value of LINK_FOLLOWS_SYMLINKS depends only on the current machine and platform. But this is not the case: On Solaris 10 systems (which don't have linkat() in libc), the behaviour of the link() function depends

Re: NFS timestamps

Hi Paul, > > - On the first machine type (x86 RHEL 3), I get the test failures > > related to NFS timestamps, mentioned in > > . > > I looked into that, and there are some obvious problems with the tests > in m4/utimes.

Re: libposix build logs

Hi Gary, > are you saying that (excepting the above) everything I reported should now > be fixed? Or just the arches quoted above? Just the listed architectures! That means, currently glibc/Linux and OSF/1 5.1. I may also be working on Solaris and HP-UX. Someone else will have to AIX. > As soon

Re: [PATCH 0/7] contents of topic/libposix for merge to master

Hi Gary, > What is the status of the libposix branch now? Should I merge the tip of > trunk into the topic branch before making a new libposix tarball for test > purposes? The status has not changed: Both you and I want to revise and rewrite the original draft patches that you put into the topic

Re: libposix build logs

Hi Bruno, On 25 Dec 2010, at 21:42, Bruno Haible wrote: > Regarding your reports on glibc/Linux systems: >>> Distcheck results by architecture and compiler: >>> >>>ix86 RHEL 3 gcc 3.2.3 (317 tests passed) >>>ix86 RHEL 4 gcc 3.4.6 (test-fcntl-h-c++.cc compile failed: