Re: printf.o HP-NonStop

Bruno Haible wrote: > Joachim Schmitz wrote: > > gllig/printf.o is not, but does not contain rpl_printf: > > $ nm -Pe gllib/printf.o > > E __stdio_fp > > F printf > > E rpl_vfprintf > > gllib/printf.o should define rpl_printf, not printf. I'm also observing this error o

Re: a note about strerror_r

On 2010-11-09 I wrote: > glibc also has a second function __xpg_strerror_r, which it enables under > the name strerror_r when _POSIX_C_SOURCE is defined to 200112L. But this > function is also not POSIX compliant, as I've just reported: >

Re: libposix build logs

I also pushed this, to simplify the logic of my previous change. It shouldn't affect whether the test succeeds. Sorry about the noise. >From f0f3beb58cf369ea9aa146c54422f834dacb84d8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 25 Dec 2010 14:08:38 -0800 Subject: [PATCH] utimens: simplif

Re: libposix build logs

On 12/25/2010 06:42 AM, Bruno Haible wrote: > - 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 t

ptsname on Solaris

On Solaris 8..11, the ptsname test fails: test-ptsname.c:99: assertion failed FAIL: test-ptsname Apparently ptsname() does not work on any BSD style pty files (/dev/pty??). Instead one has to use the recommended way to get a pty file descriptor; then ptsname works. This patch fixes the test

Re: determining the program_invocation_name

On Sat, Dec 25, 2010 at 5:32 PM, Bruno Haible wrote: > Hello Bastien, > >> We could at least in all the case implement getprogname/setprogname >> what is a well known api > > We can implement something _similar_ to getprogname. But it won't be > the same API, because >  - our function can return N

RE: socket functions on HP-NonStop

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 *" Bye, Jojo -Original Message- From: Bruno Haible [mailto:br...@clisp.org] Sent: Fr

Re: determining the program_invocation_name

Hello Bastien, > We could at least in all the case implement getprogname/setprogname > what is a well known api We can implement something _similar_ to getprogname. But it won't be the same API, because - our function can return NULL, - our function can return a truncated value, - there wil

Re: determining the program_invocation_name

> Find attached a collection of the platform dependent code snippets. > I added code for Cygwin, mingw (from progreloc.c), and OSF/1, and > tested it on the various platforms. See also http://stackoverflow.com/questions/799679 for bsd: int mib[4]; mib[0] = CTL_KERN; mib[1] = KERN_PROC; mib[2] = KER

Re: [PATCH] test-select: avoid warn_unused_result warnings

Jim Meyering wrote: > That should be ok, assuming no modern version of gcc > warns about the unused value, in spite of the "(void)" cast. Yes, this is the case, because close() is not marked as __wur in glibc's . Bruno

iswblank: fix link error in C++ mode

On Solaris 8 with gcc I'm seeing this link error: g++ -o test-wctype-c++ test-wctype-c++.o ../gllib/libgnu.a -lrt Undefined first referenced symbol in file iswblank(long) test-wctype-c++.o ld: fatal: Symbol referencing

unistd: fix link error on Solaris 8

On Solaris 8, I'm seeing this link error: g++ -o test-unistd-c++ test-unistd-c++.o ../gllib/libgnu.a -lrt -lsocket Undefined first referenced symbol in file eaccess ../gllib/libgnu.a(euidaccess.o) ld: fatal: Symb

Re: determining the program_invocation_name

n Sat, Dec 25, 2010 at 4:38 PM, Bastien ROUCARIES wrote: > On Fri, Dec 24, 2010 at 10:41 PM, Bruno Haible wrote: >> Hi, >>     Given B, you can determine C, D, E, by assuming the current directory >>     and $PATH have not changed since the program was launched. > > Or better, in a lot of system

Re: determining the program_invocation_name

On Fri, Dec 24, 2010 at 10:41 PM, Bruno Haible wrote: > Hi, >     Given B, you can determine C, D, E, by assuming the current directory >     and $PATH have not changed since the program was launched. Or better, in a lot of system when the library is loaded you could run some kind of constructor/

Re: [PATCH] test-select: avoid warn_unused_result warnings

Bruno Haible wrote: > Hi Jim, > > You wrote on 2010-10-13 in > : >> * tests/test-select.c: Include "macros.h". >> ASSERT that each call to read, write, and pipe succeeds. >> While not technically required, also check each "close".

Re: rename() over NFS

Bruno Haible wrote: > A followup to 2010-11-13 > : > > On a Linux 2.6.16.60 machine, I still get failures from 'test-rename' > and 'test-renameat' over NFS: > > test-rename.h:279: assertion failed > FAIL: test-renameat > > The

Re: libposix build logs

Hi Gary, 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: > > 133:

Re: rename() over NFS

A followup to 2010-11-13 : On a Linux 2.6.16.60 machine, I still get failures from 'test-rename' and 'test-renameat' over NFS: test-rename.h:279: assertion failed FAIL: test-renameat The reason is that the mkdir() call at l

Re: libposix build logs

Hi Gary, On 2010-11-11 I wrote: > 2010-11-11 Bruno Haible > > fcntl-h: Fix for use of C++ on glibc systems. > * lib/fcntl.in.h: Include before include_next > also on glibc systems in C++ mode. > Reported by Gary V. Vaughan . This fixed only half of the problem. This

Re: HOST_NAME_MAX on HP-NonStop

Joachim Schmitz wrote: > Problem: I seem to need automake 1.11 but only have 1.8 Yes, the file DEPENDENCIES says that you need automake 1.9.6 at least, for use with gnulib. > Meanwhile it'd be great if you could create me a new testdir Find it at http://www.haible.de/bruno/gnu/testdir-posix.tar.

Re: libposix build logs

Gary V. Vaughan wrote on 2010-10-20: > dec Tru64 5.1 Compaq C 6.5 (mbrlen.c compile failed: > rpl_mbstate_t has no linkage and a > prior > declaration in scope at > 415:./wchar.h) >

RE: HOST_NAME_MAX on HP-NonStop

This would mean I'd need a new testdir, right? It did not work with manually applying that patch alone. I'll try getting a new testdir now. Problem: I seem to need automake 1.11 but only have 1.8, and autoconf 2.62 but only have 2.59... I'll try to upgrade to 1.11.1 and 2.68 respectively. Oh w

RE: gethostname on HP-NonStop

Thanks, that should do, I'll test -Original Message- From: Bruno Haible [mailto:br...@clisp.org] Sent: Friday, December 24, 2010 4:41 PM To: Joachim Schmitz Cc: bug-gnulib@gnu.org Subject: Re: gethostname on HP-NonStop Joachim Schmitz wrote: > diff -u ./gllib/unistd.in.h.orig ./gllib/uni

RE: HP-NonStop

Yes, it does mean that, thanks. -Original Message- From: Bruno Haible [mailto:br...@clisp.org] Sent: Friday, December 24, 2010 4:28 PM To: Joachim Schmitz Cc: bug-gnulib@gnu.org Subject: Re: HP-NonStop Joachim Schmitz wrote: > Yes, but with a condition that apparently is not met (and to

prerequisites of

On OSF/1 5.1 with cc, but not with gcc, the test "checking whether wctob works" fails, because the test program does not include all prerequisites of : configure:63150: cc -O -o conftest -ieee conftest.c >&5 cc: Error: /usr/include.dtk/wchar.h, line 78: Ill-formed parameter type list. (p armty

strtok_r: fix C syntax error in autoconf macro

On OSF/1 5.1, the test "checking whether strtok_r works" succeeds with cc but fails with gcc. Why? config.log shows these errors: configure:55854: checking whether strtok_r works configure:55894: gcc -std=gnu99 -o conftest -g -O2 -Wall -mieee conftest.c >&5 conftest.c: In function 'main':