Hi Paul,
Paul Eggert writes:
> On 2025-06-08 17:39, Collin Funk wrote:
>> Posting on bug-gnulib since this test failure seems to be caused by
>> parse-datetime despite being caught by tests/date/date-debug.sh in
>> Coreutils.
>
> I installed the attached patch to Gnulib, along with a minor testc
I wanted to make a change to the bootstrap script but every time I saved
the file Emacs would open a new window with an annoying warning. This is
because of the following change documented in Emac's etc/NEWS:
*** Some historical 'time-stamp' conversions now warn.
'time-stamp-pattern' and '
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
Perhaps it would be wise for those individuals inerested in this to
have a discussion
Hi Collin,
> > already did. How far did you get on this topic?
>
> I had a look a few weekends ago, but was not able to get it working.
> Then forgot about it... Sorry, I do not have much done for you.
Nothing to be sorry about. It's OK that you have different priorities.
> +# if defined _MSC_V
Hi Bruno,
Bruno Haible writes:
> On the GitHub CI machines, I now see compilation failures on mingw:
> [...]
> This means that the mingw people made a release with that change included,
> and it is active in the GitHub CI environments.
>
> I want to get this fixed ASAP, but I don't want to dupli
Kirill Makurin wrote:
> This is the only issue I have encountered using clang-cl.exe. Everything else
> works just fine.
>
> Actually, I tried to rebuild everything from scratch with clang-cl.exe and
> noticed that iconv-2.dll, when built with clang-cl exports sprintf symbol
There's no reason w
Other than different tools and a few compiler/linker flags, everything is the
same as with MSVC. My *build script* takes care of setting variables like
INCLUDE, LIB and PATH.
This is the only issue I have encountered using clang-cl.exe. Everything else
works just fine.
Actually, I tried to reb
Hi Kirill,
> As part of my attempts to build some GNU packages with MSVC tools, I also
> tried to build them with LLVM tools which can be installed with Visual Studio
> (clang-cl.exe and lld-link.exe).
>
> When compiling source files lib/strerror.c and lib/vasnprintf.c (and possibly
> some oth
Hello,
As part of my attempts to build some GNU packages with MSVC tools, I also tried
to build them with LLVM tools which can be installed with Visual Studio
(clang-cl.exe and lld-link.exe).
When compiling source files lib/strerror.c and lib/vasnprintf.c (and possibly
some other) the followin
Hi Collin,
you wrote on 2025-04-25:
> > But that mingw change is likely to not work at all. Because gcc can
> > emit instructions that use the old i386/387 unit:
> > (a) When the program uses 'long double' values,
> > (b) When the option -mfpmath=387 is used, cf.
> > https://gcc.gnu.org/
About 3 days ago, the test-file-has-acl-2.sh started failing on Cygwin
in the GitHub CI. Both on Cygwin 3.3.6 and the current 3.6.x.
In this build from 3 days ago the test still succeeded:
https://github.com/gnu-gettext/ci-check/actions/runs/15493719484
But nothing changed in Gnulib regarding ACLs
Collin Funk wrote:
> > This is a NetBSD 10.0/arm64 machine. What about NetBSD 10.0/x86_64?
> ...
> I don't think this is needed since I think this has already been
> confirmed to fail on NetBSD 10.0/x86_64 from your CI. There is a patch
> that is applied marking it XFAIL on that platform [1].
Ah,
12 matches
Mail list logo
