8066f870c7e7fac65a4229db5f21 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 18 Mar 2025 18:12:39 -0700
Subject: [PATCH] utimensat: Make sure exit status in configure check doesn't
exceed 127.
Reported by Bruno Haible in
<https://lists.gnu.org/archive/html/bug-gnulib/2025-03/msg00061
Collin Funk wrote:
> * Packages successfully tested with gnulib-tool.py
>
> bison
> coreutils
> cppi
> cpio
> diffutils
> findutils
> freedink
> Update AC_PREREQ to 2.64 required.
> gnutls
> grep
> groff
> gzip
> inetutils
> libiconv
> mailutils
> patch
> pspp
Hi Collin,
> By the way, here is a list of packages that I have tested using your
> method here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00018.html
Good progress!
> These were done sometime in the past ~10 commits, so I would have to
> go through and double check no br
On 4/7/24 5:20 PM, Bruno Haible wrote:
> Thanks! Applied. All test-gettext-*.sh pass now. Cool.
Yep, now I can focus on trying to clean up some stuff.
By the way, here is a list of packages that I have tested using your
method here:
https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg0
On the macOS 12 machine, a Gnulib testdir now compiles fine, and usually all
tests pass.
Usually, because sometimes the test-system-quote.sh test fails, reporting
that a system() invocation failed with status 768 (= 0x0300). Sounds weird...
Log is attached.
Bruno
for input = |a z |: system
On Android, a testdir of all of Gnulib now compiles fine. The conflicts
with libc.so are resolved. The only failing tests at this point are
test-getloadavg
test-login_tty
test-nstrftime
So, it's time to update the documentation.
2023-01-22 Bruno Haible
doc: Update list of targe
On all relevant Unix platform, a testdir of all of Gnulib now compiles fine,
with the usual configurations [1].
On all native Windows platforms (mingw, MSVC, clang/MSVC), a testdir of
all of Gnulib except selected modules (see below) now compiles fine as well.
Of course there are some test failur
What is the status of http://autobuild.josefsson.org/gnulib/ ?
It is not reachable by me at the moment.
Regards,
-John
Here's the status of running a gnulib testdir of `./posix-modules --for-msvc`
on recent mingw and MSVC 14.
Volunteers to work on this are welcome. You have the Hanukkah or Christmas
season in front of you :)
==
On Mon, Nov 21, 2016 at 23:35:12 +, Pedro Alves wrote:
> BTW, do we know which programs use GNULIB_NAMESPACE?
> I believe the initial support was done for GNU Octave, but I see
> that quite recently Octave switched away from it, maybe because of
> the problems with newer GCCs (I believe fixed n
On 11/20/2016 12:23 PM, Bruno Haible wrote:
> To see where we are on C++ GNULIB_NAMESPACE support, I ran
> $ ./gnulib-tool --create-testdir --with-c++-tests --with-tests
> --dir=/tmp/testdir
> (takes one hour, be patient) and built it on a glibc system with
> $ ./configure CPPFLAGS="-DGNULIB
Hi,
To see where we are on C++ GNULIB_NAMESPACE support, I ran
$ ./gnulib-tool --create-testdir --with-c++-tests --with-tests
--dir=/tmp/testdir
(takes one hour, be patient) and built it on a glibc system with
$ ./configure CPPFLAGS="-DGNULIB_NAMESPACE= -Wall" CC=g++
$ make -k
Here are
* tests/init.sh (returns_): A new function for use in tests,
to allow for easier checking of return values, where you expect
a command to exit with failure status. By checking for a particular
exit code, you don't hide any crashes for example.
---
ChangeLog | 8
tests/init.sh
Sylvain writes:
> On Thu, Oct 24, 2013 at 08:10:17PM -0700, Ben Pfaff wrote:
>> After waiting about 72 hours, I received no comments, whether positive,
>> negative, or neutral, so I applied this to master.
>
> Thanks much!
You're welcome!
(If anything else comes up, please feel free to ping me
On Thu, Oct 24, 2013 at 08:10:17PM -0700, Ben Pfaff wrote:
> After waiting about 72 hours, I received no comments, whether positive,
> negative, or neutral, so I applied this to master.
Thanks much!
--
Sylvain
/kFreeBSD or Debian/Hurd, so
> > > I don't see this problem.
> >
> > I don't use them either, but the Debian autobuilder does :)
> > In the case of pspp, I see that it compiles fine on these
> > platforms, e,g.:
> > https://buildd.deb
ackage, am I wrong? ;)
> >
> > No, we use relocatable-prog in GNU PSPP as well. I build with it
> > all the time. But I don't use Debian/kFreeBSD or Debian/Hurd, so
> > I don't see this problem.
>
> I don't use them either, but the Debian autobuilder d
. But I don't use Debian/kFreeBSD or Debian/Hurd, so
> I don't see this problem.
I don't use them either, but the Debian autobuilder does :)
In the case of pspp, I see that it compiles fine on these
platforms, e,g.:
https://buildd.debian.org/status/fetch.php?pkg=pspp&arch=kfre
Sylvain writes:
> It's been a while (1 year 1/2) since
> http://lists.debian.org/debian-bsd/2012/05/msg00032.html and I still
> need to manually patch gnulib before releasing.
>
> If I assume the relocatable-prog module is not maintained, that I'm
> probably the only person on earth to use it, an
Hi,
It's been a while (1 year 1/2) since
http://lists.debian.org/debian-bsd/2012/05/msg00032.html and I still
need to manually patch gnulib before releasing.
If I assume the relocatable-prog module is not maintained, that I'm
probably the only person on earth to use it, and that I should just
dro
Here's the current status of the POSIX emulation modules of gnulib
on native Windows (*-*-mingw platforms), excluding known not working modules
(mgetgroups, getugroups, idcache, userspec, openpty, login_tty, forkpty,
pt_chown, grantpt, pty, savewd, mkancesdirs, mkdir-p, euidaccess, facc
test-getcwd: disambiguate exit status
* tests/test-getcwd.c (test_long_name): Return 0..7.
(main): Exit with an unambiguous exit status. The old
code yielded a mysterious mixture of two failure codes.
diff --git a/tests/test-getcwd.c b/tests/test-getcwd.c
index e9832f0..359aedb 100644
--- a/tests
On 06/19/2011 08:34 AM, Bruno Haible wrote:
>> 2 x FAIL: test-linkat
>
> On AIX 7.1, the linkat() function apparently fails with EINVAL when on
> Linux it returns other errno values. Here's the minimal change to make
> the test pass. OK to apply?
>
>
> 2011-06-19 Bruno Haible
>
>
Bruno Haible wrote:
>> 2 x FAIL: test-linkat
>
> On AIX 7.1, the linkat() function apparently fails with EINVAL when on
> Linux it returns other errno values. Here's the minimal change to make
> the test pass. OK to apply?
>
>
> 2011-06-19 Bruno Haible
>
> linkat test: Avoid test fai
> 2 x FAIL: test-linkat
On AIX 7.1, the linkat() function apparently fails with EINVAL when on
Linux it returns other errno values. Here's the minimal change to make
the test pass. OK to apply?
2011-06-19 Bruno Haible
linkat test: Avoid test failure on AIX 7.1.
* tests/
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
ChangeLog|6 ++
tests/test-atexit.sh |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 1f0ac8b..31b9c15 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-05-24 Eric Blake
+
+ atexit-tests: ensure reliable
I've fixed the trap code in init.sh.
Thanks, Dmitry.
>From 092a81622804491f13fb73f4df610db0db45b35a Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 28 Apr 2010 09:51:15 +0200
Subject: [PATCH] init.sh: ensure a more reliable exit status when exiting via
trap
* tests/init.sh
On Mon, Feb 01, 2010 at 08:58:19AM +0100, Jim Meyering wrote:
> Bruno Haible wrote:
> > Jim Meyering wrote:
> >> Imagine that the first 10 tests pass, then each of the remaining ones is
> >> killed via e.g., SIGHUP. ...
> >> a naive search for "FAIL:" in the build output would find nothing.
> >
> >
John W. Eaton wrote:
> An additional problem showed up on OS X systems:
>
> libtool: compile: g++-4.2 -DHAVE_CONFIG_H -I. -I.. -I/sw/lib/flex/include
> -I/sw/include -O0 -g -m32 -I/sw/include/freetype2 -I/sw/include/qhull
> -I/usr/include -I../libgnu -I../libgnu -I../libcruft/misc -I../liboct
John W. Eaton wrote:
> I received a report about the following error on an OS X system:
>
> In file included from /usr/include/sys/time.h:197,
>from ../libgnu/sys/time.h:40,
>from ../libgnu/sys/select.h:51,
>from /usr/include/unistd.h:5
An additional problem showed up on OS X systems:
libtool: compile: g++-4.2 -DHAVE_CONFIG_H -I. -I.. -I/sw/lib/flex/include
-I/sw/include -O0 -g -m32 -I/sw/include/freetype2 -I/sw/include/qhull
-I/usr/include -I../libgnu -I../libgnu -I../libcruft/misc -I../liboctave
-I../liboctave -I. -I. -I/
On 13-Mar-2010, Bruno Haible wrote:
| Good point. I'm adding this as an extra check in the testsuite:
Thanks for the additional changes. I modified the Octave sources so
that GNULIB_NAMESPACE is defined to gnulib and tagged all the uses
that were reported by GCC warnings. Everything worked fine
Hi John,
> OK, I tried updating and using the new c++defs module and hit an
> error with memchr and memrchr.
> ...
> In file included from /usr/include/c++/4.4/cstring:46,
>from /home/jwe/src/octave/liboctave/foo.cc:3:
> ../libgnu/string.h:298: error: no matches converting
John W. Eaton asked:
> Is there any reason not to commit the changes for the new c++defs
> module?
It was delayed because I wanted to have unit tests before committing the
changes.
It is now committed, as a series of 48 individual commits. The most interesting
part are the new idioms; documented
Is there any reason not to commit the changes for the new c++defs
module?
Earlier, I wrote:
| How can one easily find all the places where the GNULIB_NAMESPACE tag
| is needed? Is there some way we can get the compiler to help with
| this job?
|
| The reason I liked the idea of having the gnuli
Bruno Haible wrote:
> Jim Meyering wrote:
>> Imagine that the first 10 tests pass, then each of the remaining ones is
>> killed via e.g., SIGHUP. ...
>> a naive search for "FAIL:" in the build output would find nothing.
>
> Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he
>
Hi Bruno,
thanks for the additional information.
* Bruno Haible wrote on Sun, Jan 31, 2010 at 12:32:06PM CET:
> Ralf Wildenhues asked:
> > What are the "other cases" you mention, where no process was terminated
> > by the signal, but the signal delivered somewhere nonethess?
>
> When I run
>
nt when an external command is executed. The signal
> can be delivered when a builtin is executed, or even when nothing is
> executed yet. In this case, the exit status of the last command run
> before the trap has nothing related to the just delivered signal.
Thanks for the explanation
> > trap-registered command is run". Unfortunately, this comment is wrong,
> > and it seems to be a widespread misunderstanding.
> >
> > The GNU Autoconf manual says that "it is widely admitted that when
> > entering the trap `$?' should be set to the exit
Jim Meyering wrote:
> Imagine that the first 10 tests pass, then each of the remaining ones is
> killed via e.g., SIGHUP. ...
> a naive search for "FAIL:" in the build output would find nothing.
Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he
should be encouraged to invest
Ralf Wildenhues asked:
> What system and shell (version?) were your tests done on?
I could reproduce Dmitry's tests, with 'sleep 1' instead of 'sleep 0.01'.
$ for i in `seq 0 9`; do sh -c 'trap "exit \$?" TERM; while /bin/true; do
/bin/false; done' & pid=$! && sleep 1 && kill -TERM -$pid && wait
Dmitry V. Levin wrote:
> On Sun, Jan 31, 2010 at 01:04:09AM +0100, Bruno Haible wrote:
...
>> For the tests, I am inclined to provide the exit
>> code '77' (= SKIP), rather than '1' (= FAIL): If a test is terminated
>> by Ctrl-C, it has neither passed nor failed.
>
> Yes, it makes sense.
Actually,
ent is wrong,
> and it seems to be a widespread misunderstanding.
>
> The GNU Autoconf manual says that "it is widely admitted that when
> entering the trap `$?' should be set to the exit status of the last
> command run before the trap."
>
> In case of
x27;s an updated proposed patch:
2010-01-30 Bruno Haible
Dmitry V. Levin
Avoid unportable use of $? at the beginning of a shell function.
* tests/init.sh (remove_tmp_): Don't retrieve the exit status here.
(setup_): Do it directly in the trap handler here.
--
o Haible
>
> Avoid unportable use of $? at the beginning of a shell function.
> * tests/init.sh (remove_tmp_): Don't deal with exit status here.
> (setup_): Do it directly in the trap handler here.
>
> --- tests/init.sh.origSun Jan 31 01:46:23 20
Dmitry V. Levin wrote:
> > -trap 'rm -fr $tmpfiles' 1 2 3 15
> > +trap 'rm -fr $tmpfiles; exit 77' 1 2 3 15
>
> According to "Limitations of Builtins" chapter in the autoconf
> manual, plain "exit 77" is not portable; it has to be written
> as "(exit 77); exit 77".
Plain "exit 77" is not portable
On Sun, Jan 31, 2010 at 01:41:33AM +0100, Bruno Haible wrote:
[...]
> TMP_BASE=update-copyright.test
> -trap 'rm -f $TMP_BASE*' 0 1 2 3 15
> +trap 'status=$?; rm -f $TMP_BASE*; exit $status' 0
> +trap 'rm -f $TMP_BASE*; (exit 77); exit 77' 1 2 3 15
The s
ion as the first command in a trap handler can
cause problems."
Here's a proposed fix (need to handle the same problem in bootstrap yourself):
2010-01-30 Bruno Haible
Avoid unportable use of $? at the beginning of a shell function.
* tests/init.sh (remove_tmp_): D
rap handler for a signal.
* tests/init.sh (setup_): In the trap handler, exit with code 77.
Reported by Dmitry V. Levin .
Preserve the exit status at exit.
* tests/test-parse-duration.sh: In the trap handler, exit with the
intended exit status.
Preserve
On Sun, Jan 31, 2010 at 01:22:34AM +0100, Bruno Haible wrote:
> Here is part 2 of the proposed fixes.
[...]
> -trap 'rm -fr $tmpfiles' 1 2 3 15
> +trap 'rm -fr $tmpfiles; exit 77' 1 2 3 15
According to "Limitations of Builtins" chapter in the autoconf
manual, plain "exit 77" is not portable; it ha
On Sun, Jan 31, 2010 at 01:04:09AM +0100, Bruno Haible wrote:
[...]
> > Proposed patch is attached.
>
> Sorry, but I don't understand why you chose 143 as exit code, making it look
> like the process died from SIGTERM when in fact in may have been SIGINT.
> There seem to be two conventions for the
Here is part 2 of the proposed fixes.
2010-01-30 Bruno Haible
Don't continue executing a test after catching a fatal signal.
* tests/test-atexit.sh (trap 1-15): After removing the temporary files,
exit with code 77.
* tests/test-binary-io.sh (trap 1-15): Likewi
Here's part 1 of the fixes, as I would like to see it. Opinions?
2010-01-30 Bruno Haible
Don't use $? in a trap handler for a signal.
* gnulib-tool (trap 1-15): Exit with exit status 1.
* MODULES.html.sh (trap 1-15): Likewise.
Reported by Dmitr
tion 0, as explained in the Autoconf manual. The workaround
is to use the(exit n); exit n idiom. (Only needed in shell scripts
that install traps!)
- For asynchronous signals, use of '$?' is random.
So the recommended use of trap is:
- For condition 0, use the(exi
says that "it is widely admitted that when
entering the trap `$?' should be set to the exit status of the last
command run before the trap."
In case of signal handler, the exit status of the last command run
before the trap might be 128 + signal number, this usually happens when
th
onymous to
> st_mtime. That can't be fixed until we break on-disk compatibilty. How much
> of a problem is this with respect to gnulib?
It is not a big problem. Causes one test failure only. But some programs
(e.g. editors which watch the status of files being currently edited) will
47 [+0100], Bruno Haible <[EMAIL PROTECTED]> wrote:
>
> I wrote:
> > Porting gnulib to a particular platform means:
> > - doing a "gnulib-tool --create-testdir --with-tests", transferring
that
> > to the target system, and running it there, and fixing
Hello Ingo,
I wrote:
> Porting gnulib to a particular platform means:
> - doing a "gnulib-tool --create-testdir --with-tests", transferring that
> to the target system, and running it there, and fixing all the problems,
> ...
The status of this step is that, except f
Simon Josefsson wrote:
Actually, glibc declares ioctl in stropts.h too. However, stropts.h is
not mention anywhere in the glibc manual. The glibc manual says the
ioctl function is declared in sys/ioctl.h. The man page for ioctl on my
system says sys/ioctl.h.
As of Fedora's glibc-2.8-8, there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 10/10/2008 3:01 AM:
>
> Does the new POSIX document change anything? I notice that "ioctl.h"
> doesn't result in anything on the current opengroup.org site.
Yes. It deprecates STREAMS, and renders the use of obsolet
Simon Josefsson wrote:
> Actually, glibc declares ioctl in stropts.h too. However, stropts.h is
> not mention anywhere in the glibc manual. The glibc manual says the
> ioctl function is declared in sys/ioctl.h. The man page for ioctl on my
> system says sys/ioctl.h.
Yes. And additionally,
- a
Bruno Haible <[EMAIL PROTECTED]> writes:
> Where should ioctl() be declared? Certainly not in . Most
> platforms have it in . Only AIX and Solaris declare it in
> instead. POSIX specifies it should be declared ,
> but many platforms don't have (and who needs STREAMS anyway?).
> The de-facto stan
Where should ioctl() be declared? Certainly not in . Most
platforms have it in . Only AIX and Solaris declare it in
instead. POSIX specifies it should be declared ,
but many platforms don't have (and who needs STREAMS anyway?).
The de-facto standard is apparently .
The ioctl() declaration is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/10/2008 10:26 PM:
| | Checking ./182.mkstemp
| ...
| | -1
| | +256
|
| Testsuite bug; I'll have to patch doc/m4.texinfo. Basically, I cannot
| assume that a failed 'test -f foo-*' exits with status
nal 255 (255<<8 == 65280; m4's sysval macro
shifts the status of child processes that die from signals in order to
distinguish from normal exit). That seems rather fishy - generally there
is no signal 255. On your platform, is there a way to force a child
process in system(3) to exit with a kn
tests/test-copy-file-sameacls.c: New file.
The status is the following:
LinuxOK
Solaris FAIL
FreeBSD OK
HP-UXFAIL
Tru64FAIL
AIX FAIL
MacOS X FAIL
Cygwin FAIL
IRIX OK
Platforms without ACLs (OpenBSD, mingw) OK
The failures are of different categories:
- On MacOS X,
I've fixed a few robustness problems in git's git-cvsserver. Once
savannah is running a version of git with that change (the patch is
already upstream, and will be in git-1.5.3), I'll feel better about
switching gnulib's "upstream" repo to git, and letting old-timers (:-)
use git's cvsserver inter
Bruno Haible <[EMAIL PROTECTED]> writes:
> I hope these changes are OK with you. If not, feel free to revert them.
Thanks very much for taking the time to proofread all that. My change
was a bit disruptive, and I was worried about running into problems
with it on on less-common platforms. Your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/18/2007 7:16 PM:
> Compiling a testdir
> - on Linux (to test the case where gettimeofday is present),
> - in a cross-compile to Cygwin (to test the case where gettimeofday is
> assumed to clobber localtime's buffe
Compiling a testdir
- on Linux (to test the case where gettimeofday is present),
- in a cross-compile to Cygwin (to test the case where gettimeofday is
assumed to clobber localtime's buffer),
- in a cross-compile to Mingw (to test the case of missing gettimeofday)
I again come up with sev
Paul Eggert wrote:
> The main idea here is that we should try to avoid separate include
> files like "gettimeofday.h" for declarations that POSIX says should be
> in a standard file like . Instead, we should patch
> by wrapping it; that way the user code can just code to
> the POSIX standard.
Ye
Paul Eggert CS.UCLA.EDU> writes:
>
> The main idea here is that we should try to avoid separate include
> files like "gettimeofday.h" for declarations that POSIX says should be
> in a standard file like . Instead, we should patch
> by wrapping it; that way the user code can just code to
> the
Bruno Haible <[EMAIL PROTECTED]> writes:
> - Coreutils has a comment explaining why it is useful to compute the
> microseconds as
> milliseconds * 1000 + 999
> rather than as
> milliseconds * 1000.
It's useful for that particular case, but there are other cases
where it's not useful
Bruno Haible <[EMAIL PROTECTED]> writes:
> (together with more *-tests modules).
Yes, writing self tests for modules would be a good thing. Maybe the
autobuild page could say 'Success (0)' and 'Success (4)' etc depending
on how many self-tests were successful...
/Simon
Le mercredi 17 janvier 2007 à 02:05 +0100, Bruno Haible a écrit :
> Yoann Vandoorselaere asked:
> > I'm currently working on a win32 port for libprelude, and we're missing
> > a gettimeofday module working under win32.
> >
> > I've noticed an attempt to implement win32 support to the current modul
The revised gettimeofday module requires IMO the following changes in
gnulib. Opinions? Paul?
--- lib/gettime.c 13 Sep 2006 22:38:14 - 1.7
+++ lib/gettime.c 17 Jan 2007 11:48:37 -
@@ -1,6 +1,6 @@
/* gettime -- get the system clock
- Copyright (C) 2002, 2004, 2005, 20
Two additional modifications:
- Code was missing for the case
HAVE_GETTIMEOFDAY && !HAVE_GETTIMEOFDAY_POSIX_SIGNATURE.
- Coreutils has a comment explaining why it is useful to compute the
microseconds as
milliseconds * 1000 + 999
rather than as
milliseconds * 1000.
2007-01-17 Brun
Simon Josefsson wrote:
> I started a daily build of gnulib for mingw32 now, there are some
> initial results on:
>
> http://autobuild.josefsson.org/gnulib-mingw32/
> ...
> The Testdrive systems appear to be back online again, so it may be
> possible to do daily builds on more exotic platforms as w
on the same day).
Perhaps the summary should contain the latest build status for each
platform -- sorted on platforms which has problems. I'm not that fond
of HTML programming, but I hope to improve this aspect eventually...
The Testdrive systems appear to be back online again, so it may
Yoann Vandoorselaere asked:
> I'm currently working on a win32 port for libprelude, and we're missing
> a gettimeofday module working under win32.
>
> I've noticed an attempt to implement win32 support to the current module
> was discussed previously:
> http://thread.gmane.org/gmane.comp.lib.gnuli
Hi,
I'm currently working on a win32 port for libprelude, and we're missing
a gettimeofday module working under win32.
I've noticed an attempt to implement win32 support to the current module
was discussed previously:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/4155/focus=5770
However, t
A few days ago, Ulrich Drepper and I were talking, and I mentioned
the openat[*] problem (that Solaris has it, but Linux doesn't, and
that it'd be so nice to be able to use it in places like fts.c,
mkdir-p.c, remove.c, etc.). Sure, we have replacement functions
in gnulib's lib/openat.c, and they w
83 matches
Mail list logo
