On 5/14/21 5:07 PM, Bruno Haible wrote:
I won't spend any more time on fixing this Solaris-only code — when we
have code that works on all platforms in GNU libsigsegv.
At first I fixed this by having c-stack simply defer to libsigsegv if
installed, but I found that this didn't work on gcc211 i
I wrote:
> Clearly, the faulting_address variable's value is bogus.
In fact, GNU libsigsegv already knows how to cope with this problem:
https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=src/fault-solaris11-sparc.h
Bruno
The newest m4 snapshots don't pass all their tests on Solaris 11.3/sparc64:
stackovf.test fails.
This happens also when GNU libsigsegv is installed and --with-libsigsegv-prefix
is given, because the c-stack.m4 autoconf test now insists in ignoring
GNU libsigsegv when it thinks that the Solaris heu
Nicholas Gaya wrote:
> The process hierarchy starts with tclsh (MacPorts), then a bunch of layers of
> make and sh (from oath-toolkit's recursive `make check`), and finally the
> test-fcntl executable. I was using MacPorts' "trace mode", which seems to be
> responsible for the particularly high
Simon Josefsson wrote:
> It seems there are only
> two tests that unexpectedly pass, the test-asyncsafe-linked_list-weak.sh
> and test-asyncsafe-linked_list-strong.sh. Any ideas on these?
I was meaning to clean this up soon, but haven't gotten around to it. So,
let me move them into a tests modul
Bruno Haible writes:
> Simon Josefsson wrote:
>> Was anyone working on setting up CI/CD for gnulib on GitLab?
>> I recall there was a private project for it, but I don't have access.
>> Any reason for this? I have become rather aquinted with GitLab CI/CD
>> lately so it would be easy for me to s
Simon Josefsson wrote:
> Was anyone working on setting up CI/CD for gnulib on GitLab?
> I recall there was a private project for it, but I don't have access.
> Any reason for this? I have become rather aquinted with GitLab CI/CD
> lately so it would be easy for me to setup something from scratch.
Hi Simon,
> > Assuming I am a GNU package maintainer and I read this paragraph. How do
> > I know whether my package uses the "old serial test harness"? Can I
> > determine this by looking at configure.ac? Or at the main Makefile.am?
>
> I suspect almost everyone is using the parallel test harnes
On 5/14/21 7:42 PM, Simon Josefsson via Gnulib discussion list wrote:
> Certainly! Was anyone working on setting up CI/CD for gnulib on GitLab?
> I recall there was a private project for it, but I don't have access.
> Any reason for this? I have become rather aquinted with GitLab CI/CD
> lately s
Bruno Haible writes:
> Hi Simon,
>
>> +Replace @code{LOG_COMPILER} with @code{TESTS_ENVIRONMENT} if you are
>> +using the old serial test harness.
>
> Assuming I am a GNU package maintainer and I read this paragraph. How do
> I know whether my package uses the "old serial test harness"? Can I
> d
Bruno Haible writes:
>> However I think these lists often become outdated. In my view, to claim
>> that a platform is supported by a software project, you should have
>> continous building for the platform. Otherwise support is reactive and
>> tends to be spurious.
>
> Gnulib is a hobbyist, vol
On Solaris 11.3 (the machine gcc211.fsffrance.org, in 64-bit mode), there
are test failures:
FAIL: test-calloc-gnu
FAIL: test-malloc-gnu
FAIL: test-realloc-gnu
FAIL: test-reallocarray
Each of these tests takes about 30 seconds before failing, and is not
immediately reactive to Ctrl-C.
$ ti
On 5/14/21 6:19 PM, Bruno Haible wrote:
> Gnulib is a hobbyist, volunteer project. We can not provide the same
> level of support as, for example, you do with your company. Therefore —
> unless someone comes up and invests the necessary time and money for the
> multi-platform continuous integration
Simon Josefsson wrote:
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/DEPENDENCIES
>
> Ironically, it does not mention 'join' but mention a lot of other tools.
Good point. Fixed through the patch below.
> However I think these lists often become outdated. In my view, to claim
> that a plat
Am 14. Mai 2021 um 12:39 Uhr schrieb "Bruno Haible":
> Yes, I agree. That's the proper way to fix it. I applied and pushed your
> change.
> Thanks!
Thanks! Very much appreciated.
Markus
Hi Simon,
> +Replace @code{LOG_COMPILER} with @code{TESTS_ENVIRONMENT} if you are
> +using the old serial test harness.
Assuming I am a GNU package maintainer and I read this paragraph. How do
I know whether my package uses the "old serial test harness"? Can I
determine this by looking at configu
On Solaris 11.3/sparc64, I see a test failure:
FAIL test-malloc-gnu (exit status: 1)
Now, there are 3 possible reasons for exit status 1 in this test. This makes
the investigation of the cause unnecessarily time consuming.
Similarly, test-reallocarray has exit statuses 1, 2, 3, 4, but this doe
Bernhard Voelker writes:
> On 5/12/21 7:58 PM, Simon Josefsson via Gnulib discussion list wrote:
>> It would be nice to write a 'join' replacement for gnulib-tool, as that
>> is the only thing that needs coreutils for bootstrapping libidn2 on
>> alpine. But it is not important, and with your pat
Bernhard Voelker wrote:
> I'm wondering if we have a list of supported platforms for maintainers
Not officially. We just assume that no one will be silly enough to use e.g.
Solaris 10 — without added GNU tools — as their development platform. Every
platform, even Solaris 10 and embedded platforms
On 5/12/21 7:58 PM, Simon Josefsson via Gnulib discussion list wrote:
> It would be nice to write a 'join' replacement for gnulib-tool, as that
> is the only thing that needs coreutils for bootstrapping libidn2 on
> alpine. But it is not important, and with your patch things work as
> good as they
Further testing quickly found a small bug, pushed.
/Simon
From 784fdea59920d69998b59ab326c11a8a2a93ef88 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 14 May 2021 15:03:25 +0200
Subject: [PATCH] valgrind-tests: Fix LOG_VALGRIND when valgrind is missing.
* m4/valgrind-tests.m4: Clear a
Hi. I have pushed the attached patch. It should be completely
backwards compatible, or there is a bug, so please test this. It adds
two new variables to allow both developers and users to influence the
valgrind options used. You may want to re-read the manual, I updated it
to assume people use
Bastien ROUCARIES wrote:
> - close the end of the pipe, but it does not break poll(2), and
> moreover in multithread context
> it is not safe due to fd reuse
Yes, close() in multithreaded applications needs to be done carefully,
to avoid that unintended operations get done to the next file that
is
Hi,
Markus Mützel wrote:
> On second thought, the header should probably better not re-define
> STARTUPINFO.
> The following alternative change might be saver:
>
> From 84df3e82f88799d211bd4f5147473b238937d458 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Markus=20M=C3=BCtzel?=
> Date: Thu, 6 May
24 matches
Mail list logo
