Hi Bruno,
On Jan 30 00:43, Bruno Haible wrote:
> Hi Corinna,
>
> Corinna Vinschen wrote:
> > > I keep the Cygwin (32-bit) CI, since that is running a fixed release
> > > (3.3.6) —
> > > no risk of regressions caused by Cygwin.
> >
> > We released
Hi Bruno,
On Dec 25 07:42, Bruno Haible wrote:
> The newest Cygwin release (3.5.5) has three major regressions:
> - bash hangs [1]
> - access() behaviour changed [2]
> - raise() produces random behaviour [3]
>
> The first one has the potential to hang the CI for 6 hours; the second and
> th
Hi Bruno,
On Nov 14 19:33, Bruno Haible wrote:
> [CCing bug-gnulib]
>
> Hi Corinna,
>
> > Looking into all the BSD variants of random(), I found that OpenBSD
> > defaults the random() function to return non-deterministic output. It
> > works like this:
> >
> > - A global var random_determinis
On Feb 17 09:30, Reuben Thomas wrote:
> On Sat, 11 Feb 2023 at 12:40, Corinna Vinschen wrote:
>
> > On Feb 11 12:29, Reuben Thomas wrote:
> > > On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen
> > wrote:
> > >
> > > >
> > > > If
On Feb 11 12:29, Reuben Thomas wrote:
> On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen wrote:
>
> >
> > If you're sure that the native recode.dll has been built, is it possible
> > that it's just not found, because it's not in Windows' DLL search path
On Feb 11 11:36, Reuben Thomas wrote:
> On Fri, 10 Feb 2023 at 14:21, Bruno Haible wrote:
>
> > It complains about the symbols defined in libiconv. This means, you need
> > to invoke the Gnulib module 'iconv' and add $(LIBICONV) or $(LTLIBICONV)
> > to the LDFLAGS.
> >
>
> Bruno to the rescue ag
Hi Reuben,
On Feb 7 14:22, Corinna Vinschen wrote:
> On Feb 6 20:50, Reuben Thomas wrote:
> > On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote:
> >
> > > 1. 'recode' is updated to a current gnulib and publish a corresponding
> > > tarball.
On Feb 6 20:50, Reuben Thomas wrote:
> On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote:
>
> > 1. 'recode' is updated to a current gnulib and publish a corresponding
> > tarball. (Hi Reuben :) )
> >
>
> I've updated gnulib in recode git; I'd be grateful if I could have a report
> that it'
On Feb 6 21:38, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > I just ran the setlocale_null-mt-* tests with gnulib from git master
> > under Cygwin with my newlib patch, and the tests succeeded. I checked
> > that configure is doing the right thing and config
On Feb 6 18:37, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > This patch will be in the next Cygwin release 3.4.6.
>
> Thanks!
>
> > I'm just a bit fuzzy what patches will be required for gnulib now...
>
> With this patch, the setlocale_null lock sho
Hi Bruno,
On Feb 5 22:22, Corinna Vinschen wrote:
> On Feb 5 21:41, Bruno Haible wrote:
> > Another option — since we are talking about a single symbol and a single
> > platform — would be if the locking for setlocale_null were not necessary
> > on Cygwin in the first pla
On Feb 5 21:41, Bruno Haible wrote:
> Hi Corinna,
>
> Thanks for the heads-up and patch.
>
> > Note that dllimport/dllexport decorations are not at all required on
> > Cygwin for quite some time.
>
> Is this true in all circumstances? I thought that when --disable-auto-import
> is in use AND th
Note that dllimport/dllexport decorations are not at all required on
Cygwin for quite some time.
Worse, this breaks building DLLs and DLL import libs using libtool.
On Cygwin --export-all-symbols is default. However, if just a single
symbol is decorated with dllexport, ld switches to exporting o
On Dec 19 15:41, Corinna Vinschen wrote:
> On Dec 19 08:51, Bruno Haible wrote:
> > Corinna Vinschen wrote in
> > <https://lists.gnu.org/archive/html/grep-devel/2018-12/msg00039.html>:
> > > it would be
> > > pretty nice if that code could get reverted ba
On Dec 19 08:51, Bruno Haible wrote:
> Corinna Vinschen wrote in
> <https://lists.gnu.org/archive/html/grep-devel/2018-12/msg00039.html>:
> > it would be
> > pretty nice if that code could get reverted back in to support
> > non-BMP charsets even on Cygwin.
>
>
yet. This might be a nice project for somebody who wants to contribute
to Cygwin, since its implementation is mostly independent from the
already existing functionality.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
's no reason to make it bigger. On UCS-2 and UTF-16
platforms sizeof(wint_t) == 4 because it must be able to hold EOF as
well. So, why not just use the wint_t type for the time being?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
y use 'x' instead of 'ww' when
> replacing existing 'w' in POSIX APIs.
May I suggest a compromise? What about "xwchar_t"? It avoids the
potential typo by accidentally dropping the second w. It still contains
"wchar" which implies that it's a *wide* char type. And the x could be
read as "extended".
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
IN32__ manually, deserves the result.
>
> But such a user will then write a mail to a mailing list, and it will take
> time for me (or someone else) to investigate and answer it. By writing
> #if (defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__
> I avoid this potential problem.
Ok. However, the other variation
#if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__
should be only used in very rare circumstances. Usually it just means
that some unnecessary Windowism is used on Cygwin, and that there's
probably a POSIXy equivalent. If not, kick us here on the list and
we can discuss it.
> Thanks again for your reply and for the hint to the bug in libiconv's code.
You're welcome and thanks for this fruitful discussion. I'm glad if we
can find a well-working compromise for some of the problems, especially
in the unfortunate UTF-16 case.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
19 matches
Mail list logo
