On Fri, 9 Feb 2018 19:59:26, Brian Inglis wrote:
$ locale -av
...
locale: zh_HK archive: /proc/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
---
language | Chinese (Traditional)
territory | Hong Kong SAR
codeset
On 2018-02-09 18:48, Steven Penny wrote:
> I see that the "zh_HK" locale and friends exist:
>
> $ locale -a | grep zh_HK
> zh_HK
> zh_HK.utf8
> zh_HK@cjknarrow
> zh_HK.utf8@cjknarrow
>
> However I am not seeing the "zh_HK.big5" or "zh_HK.big5hkscs" variants.
> Installing "gettext"
I see that the "zh_HK" locale and friends exist:
$ locale -a | grep zh_HK
zh_HK
zh_HK.utf8
zh_HK@cjknarrow
zh_HK.utf8@cjknarrow
However I am not seeing the "zh_HK.big5" or "zh_HK.big5hkscs" variants.
Installing "gettext" adds these:
bokmal catalan croatian czech danish dansk d
In 2014 there was a query about i686-w64-mingw32-gcc in the case that
/usr/bin was not on the PATH, and the responses then said that the issue
would be fixed in the next release.
I got bitten now because when I use ssh to execute a command on a remote
cygwin64 system /bin gets on PATH but /usr
On 2018-02-08 20:51, Ameya Vikram Singh wrote:
> I tried the latest ViM package(vim-8.0.1428-1).
> Even the current version has the same problem.
>
> I do have the **ruby** runtime libraries installed and even the
> development headers package also installed.
Confirmed. The configure script chan
On Feb 9 13:12, David Allsopp wrote:
> Corinna Vinschen wrote:
> > On Feb 9 11:29, David Allsopp wrote:
> > > [...]
> > > When this was originally encountered for 64-bit MSVC (this was all
> > > added before Cygwin64 existed), the solution at the time was to keep
> > > the preferred base addresse
Corinna Vinschen wrote:
> On Feb 9 12:40, Corinna Vinschen wrote:
> > On Feb 9 11:29, David Allsopp wrote:
> > > > Apart from that, not only Cygwin DLLs but also the Windows system
> > > > DLLs are all loaded and relocated to the area beyond 0x1:8000,
> > > > so relocation beyond the 32 bit a
Corinna Vinschen wrote:
> On Feb 9 11:29, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > On Feb 8 11:47, David Allsopp wrote:
> > > > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by
> > > > the
> > > > 0x2 base address requirement added in rebase 4.4.4.
> > > > P
On Feb 9 12:40, Corinna Vinschen wrote:
> On Feb 9 11:29, David Allsopp wrote:
> > > Apart from that, not only Cygwin DLLs but also the Windows system DLLs
> > > are all loaded and relocated to the area beyond 0x1:8000, so
> > > relocation beyond the 32 bit address space is no generic problem
On Feb 9 11:29, David Allsopp wrote:
> Corinna Vinschen wrote:
> > On Feb 8 11:47, David Allsopp wrote:
> > > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> > > 0x2 base address requirement added in rebase 4.4.4. Possible
> > > fixes for this at the bottom.
> > >
Corinna Vinschen wrote:
> On Feb 8 11:47, David Allsopp wrote:
> > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> > 0x2 base address requirement added in rebase 4.4.4. Possible
> > fixes for this at the bottom.
> > [...]
> > $ ocaml
> > OCaml version 4.
Corinna Vinschen wrote:
> On Feb 8 11:47, David Allsopp wrote:
> > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> > 0x2 base address requirement added in rebase 4.4.4. Possible
> > fixes for this at the bottom.
> >
> > Commit bfd383 in the rebase sources introduces
On 09/02/2018 09:38, Stuart Rothrock wrote:
I have downloaded setup from the Cygwin main page for years with no issues.
Starting today, Chrome refuses to download it and claims it contains a
virus. Thought it might be better to be safe than sorry so I am sending
this list for further review.
Chr
I have downloaded setup from the Cygwin main page for years with no issues.
Starting today, Chrome refuses to download it and claims it contains a
virus. Thought it might be better to be safe than sorry so I am sending
this list for further review.
Chrome Download - setup-x86.exe - Virus detected
14 matches
Mail list logo
