The variables appear to be set to the path of the compiled environment.
$ cygcheck -cd libjson-c-devel
Cygwin Package Information
Package Version
libjson-c-devel 0.16-1
$ cat /usr/lib/pkgconfig/json-c.pc
prefix=/pub/devel/json-c/json-c-0.16-1.x86_64/inst/usr
exec_prefix=/pub/dev
On 2023-08-28 05:47, Joshuah Hurst via Cygwin wrote:
On Mon, Aug 28, 2023 at 1:08 AM Jeremy Hetzler via Cygwin
wrote:
On Sun, Aug 27, 2023 at 2:25 PM Ed Morton via Cygwin
wrote:
This (original email below) turned out to be a general cygwin issue, not
a gawk issue:
$ LC_ALL=C sed 's/x/y/' $
On Mon, 28 Aug 2023 14:07:44 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> > For message-oriented sockets, a zero-length transport datagram is sent.
>
> And how is that acceptable? This will interject a message into some
> application protocol,
> which may not be expected at the applicat
On 8/28/23, Cary Lewis via Cygwin wrote:
> On one machine I have cygwin version 3.1.7(0.340/5/3), I can copy cygwin
> binaries and the corresponding dlls to a folder and then run the cygwin
> programs without any problems.
>
> But on another machine I have a newer cygwin, 3.4.7-1.x86_64, and wh
> For message-oriented sockets, a zero-length transport datagram is sent.
And how is that acceptable? This will interject a message into some
application protocol,
which may not be expected at the application level.
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cy
On Mon, 28 Aug 2023 13:37:11 +
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote:
> > You seems to reffer Linux man, however, this patch calls
>
> I was referring to a known behavior. Your patch gets to call send(s,"",0),
> which is technically a write call, and which in this case, falls into an
> You seems to reffer Linux man, however, this patch calls
I was referring to a known behavior. Your patch gets to call send(s,"",0),
which is technically a write call, and which in this case, falls into an
undefined
domain for its argument, and hence, may be expected to change without notice.
T
On one machine I have cygwin version 3.1.7(0.340/5/3), I can copy cygwin
binaries and the corresponding dlls to a folder and then run the cygwin
programs without any problems.
But on another machine I have a newer cygwin, 3.4.7-1.x86_64, and when I
do the same thing, the programs do not work:
e
On Mon, Aug 28, 2023 at 1:08 AM Jeremy Hetzler via Cygwin
wrote:
>
> On Sun, Aug 27, 2023 at 2:25 PM Ed Morton via Cygwin
> wrote:
> >
> > This (original email below) turned out to be a general cygwin issue, not
> > a gawk issue:
> >
> > $ LC_ALL=C sed 's/x/y/' $(seq 100)
> > Segmentation fau
On Sun, Aug 27, 2023 at 2:35 PM Corinna Vinschen via Cygwin
wrote:
>
> On Aug 26 19:44, Martin Wege via Cygwin wrote:
> > On Fri, Aug 25, 2023 at 2:19 PM Corinna Vinschen via Cygwin
> > wrote:
> > >
> > > On Aug 23 01:05, Roland Mainz via Cygwin wrote:
> > > > Note that Cygwin does not interpret
On Aug 28 07:35, Cedric Blancher via Cygwin wrote:
> On Sun, 27 Aug 2023 at 14:35, Corinna Vinschen via Cygwin
> wrote:
> > As for FIFOs on NFS, as I wrote, they never worked as desired on NFS.
> > For kicks I tried back until Cygwin 3.3. Given this isn't a regression,
> > it won't be fixed for C
On Aug 27 18:13, Cary Lewis via Cygwin wrote:
> In a cygwin process that is started either from mintty or bash directly the
> following:
>
> $ user=234
>
> $ ./cat <(echo $user)
> 234
> works as expected.
>
> But after a chroot:
>From https://cygwin.com/cygwin-ug-net/highlights.html:
chroot
On Sun, 27 Aug 2023 13:24:55 -0500
Ed Morton wrote:
> This (original email below) turned out to be a general cygwin issue, not
> a gawk issue:
>
> $ LC_ALL=C sed 's/x/y/' $(seq 100)
> Segmentation fault (core dumped)
>
> $ LC_ALL=C grep 'foo' $(seq 100)
> Segmentation fault (core dumped)
13 matches
Mail list logo
