The comment in clean-temp.h says that temp files/directories will be
"automatically removed when the program exits either normally or through a
fatal signal" .
However, the code in clean-temp.c seems only to deal with the fatal signal case.
Consequently, in most cases, they don't get removed (ob
Hi,
John Darrington wrote:
> The comment in clean-temp.h says that temp files/directories will be
> "automatically removed when the program exits either normally or through a
> fatal signal" .
>
> However, the code in clean-temp.c seems only to deal with the fatal signal
> case.
> Consequently
On 06/16/2011 12:12 AM, Bruno Haible wrote:
I wrote:
Please review and comment. I'll wait for objections for a week.
The week is over. I have now pushed the series of patches, after doing an
additional test with --create-megatestdir.
I found another regression from this patch series.
On Sol
Hi,
Tom G. Christensen wrote:
> I found another regression from this patch series.
>
> On Solaris 2.6 test-getloadavg now fails to link:
> gcc -std=gnu99 -g -O2 -L/usr/tgcware/lib -Wl,-R,/usr/tgcware/lib -o
> test-getloadavg test-getloadavg.o ../gllib/libgnu
> .a -lkvm -lelf -lm -lm -lm
On 06/16/11 14:31, Jack Kelly wrote:
It might be better to have config.h do something like this:
#ifdef CONFIG_H
# error "config.h included twice"
#endif
#define CONFIG_H
Warning: Quite a few misbehaving packages actually install their config.h.
It might be better to have an autoconf macro,
On AIX 6.1 and 7.1, the tests for isinf and isfinite don't link:
xlc -D_ALL_SOURCE -O -g -o test-isinf test-isinf.o ../gllib/libgnu.a
ld: 0711-317 ERROR: Undefined symbol: ._isinff
xlc -D_ALL_SOURCE -O -g -o test-isfinite test-isfinite.o ../gllib/libgnu.a
ld: 0711-317 ERROR: Un
Hi Eric,
In pathmax.h one of the possible replacement values for PATH_MAX on systems
that don't define it (currently HP-UX and GNU/Hurd) is an expression
involving pathconf().
But tests/test-stat.h line 20 declares an array of size PATH_MAX. So - at
least with pre-C99 compilers - it is assuming t
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", line 53: error 15
On HP-UX 11.31, I'm getting these link errors:
cc -Ae -D_XOPEN_SOURCE=500 -O -g -o test-fdopendir test-fdopendir.o
libtests.a ../gllib/libgnu.a libtests.a
/usr/ccs/bin/ld: Unsatisfied symbols:
program_name (first referenced in ../gllib/libgnu.a(error.o)) (data)
gmake[2]: *** [test-fdopendir
A testdir for all `./posix-modules` leads to the following test failures.
Summary:
13 x FAIL: test-poll
10 x FAIL: test-getcwd
3 x FAIL: test-utimensat
3 x FAIL: test-utimens
3 x FAIL: test-perror2
3 x FAIL: test-fsync
3 x FAIL: test-ceilf-ieee
2 x FA
Eric Blake wrote on 2011-06-07:
> > It's because /usr/include/string.h on this system does not always declare
> > strerror_r (only if _REENTRANT or _THREAD_SAFE is defined). This fixes it
> > (without requiring the 'strerror_r' module).
>
> This raises an interesting question. The 'error' module
On Sat, Jun 18, 2011 at 8:33 PM, Bruno Haible wrote:
> Hi Eric,
>
> In pathmax.h one of the possible replacement values for PATH_MAX on systems
> that don't define it (currently HP-UX and GNU/Hurd) is an expression
> involving pathconf().
>
> But tests/test-stat.h line 20 declares an array of size
On 06/18/11 15:18, James Youngman wrote:
> I suspect that the most useful thing we can do in gnulib is define
> PATH_MAX to a non-constant expression on all platforms, even the ones
> in which it is normally a constant expression.
That goes a bit too far, I'd think. Some code assumes
a constant P
IMHO ...
I suspect that the most useful thing we can do in gnulib is define
PATH_MAX to a non-constant expression on all platforms,
And intentionally break loads of existing code?
I am highly doubtful that that is "useful"; "painful" sounds more
accurate :).
I am aware that conceptually
Eric Blake explained on 2011-06-09:
> > what's the difference between
> > i686-pc-mingw32 and i686-w64-mingw32?
>
> i686-pc-mingw32 is the old mingw32 project; it is not as actively
> maintained today, but is still the project used by cygwin. Right now,
> it uses dwarf exceptions.
>
> i686-w64-m
On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry wrote:
> IMHO ...
>
> I suspect that the most useful thing we can do in gnulib is define
> PATH_MAX to a non-constant expression on all platforms,
>
> And intentionally break loads of existing code?
> I am highly doubtful that that is "useful"; "p
James, Eric,
> we're trying to get rid of a findutils construct:
>
> -#if defined SIGCLD && !defined SIGCHLD
> -# define SIGCHLD SIGCLD
> -#endif
>
> and need to know if gnulib's replacement needs to guarantee
> this definition of SIGCHLD, or if the only platforms where only SIGCLD
> existed are
Eric,
Here's some info about the test-perror2 failures:
> 3 x FAIL: test-perror2
All three failures at line 112: ASSERT (strstr (buf, err));
On OpenBSD 4.9:
i = 1, err = "Success", buf = "Undefined error: 0\n"
config.status:
S["REPLACE_STRERROR_R"]="1"
S["REPLACE_STRERROR"]="1"
S["HAVE_
> 3 x FAIL: test-fsync
When stdin is connected to a socket (or pipe?) set up by sshd:
- On MacOS X, fsync (0) fails with ENOTSUP instead of EINVAL.
- On AIX 7.1, fsync (0) fails with EBADF instead of EINVAL.
This patch fixes the failure, by relaxing the test.
2011-06-18 Bruno Haible
Hello,
* James Youngman wrote on Sun, Jun 19, 2011 at 12:57:01AM CEST:
> On Sat, Jun 18, 2011 at 11:24 PM, Karl Berry wrote:
> > I suspect that the most useful thing we can do in gnulib is define
> > PATH_MAX to a non-constant expression on all platforms,
> >
> > And intentionally break loa
20 matches
Mail list logo
