Re: stdnoreturn: fix for Cygwin

[Eric Blake]

On 08/16/2017 07:59 PM, Eric Blake wrote:
> Adding cygwin list...
> 
> On 08/16/2017 07:01 PM, Bruno Haible wrote:
>> On Cygwin 1.7.30, I'm seeing this testdir build failure, when compiling
>> test-stdnoreturn.c:
>>
>> /usr/include/stdlib.h:66:28: error: expected ‘,’ or ‘;’ before ‘)’ token
>>  _VOID _EXFUN(abort,(_VOID) _ATTRIBUTE ((noreturn)));
> 
>> +
>> +   Similarly, on Cygwin, standard include files contain declarations like
>> + void __cdecl abort (void) __attribute__ ((noreturn));
>> +   "#define noreturn _Noreturn" would cause this declaration to be rewritten
>> +   to the invalid
>> + void __cdecl abort (void) __attribute__ ((__attribute__ 
>> ((__noreturn__;
> 
> Hmm. It's evil for any system .h file to ever use
> __attribute__((barename)), since barename is in the user's namespace and
> can therefore be defined to anything else, possibly breaking the header
> (as you just proved).  Hopefully, the problem goes away if cygwin
> patches its headers to use __attribute__((__noreturn__)), so that gnulib
> can then define noreturn at will.
> 
> I'll look into patching Cygwin to fix all barename attributes I can find
> that should be __barename__ instead.

On a closer look, I've already done this, several years ago (although a
few more have crept in since then):
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=ada456dcf

Bruno, your cygwin installation of 1.7.30 is old, compared to current 2.8.2

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: missing poppler and openjpeg packages on mirrors

[Eric Blake]

On 08/16/2017 05:56 PM, Isaac Hanson wrote:
> It seems that some packages have recently gone missing from many
> cygwin mirrors.  Specifically, I have noticed all the poppler and
> openjpeg packages are gone, while still in the setup.ini and
> dependencies of other packages.
> 
> setup.exe reports "HTTP status 404 fetching" and lists the URL to the
> package, for example,
> "http://cygwin.mirror.constant.com/x86_64/release/poppler/libpoppler66/libpoppler66-0.52.0-1.tar.xz;
> 
> Any help would be appreciated.

As posted earlier on the list:

sourceware.org is having some fallout from a hardware upgrade (see [1]).

Some things got restored from backup.  Work is ongoing.

[1] https://www.sourceware.org/ml/overseers/2017-q3/msg00060.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

[PATCH] headers: avoid bareword attributes

[Eric Blake]

Always use the __-decorated form of an attribute name in public
headers, as the bareword form is in the user's namespace, and we
don't want compilation to break just because the user defines the
bareword to mean something else.

Signed-off-by: Eric Blake 
---
 winsup/cygwin/include/cygwin/config.h | 2 +-
 winsup/cygwin/include/cygwin/signal.h | 2 +-
 winsup/cygwin/include/pthread.h   | 4 ++--
 winsup/cygwin/include/sys/ucontext.h  | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/include/cygwin/config.h 
b/winsup/cygwin/include/cygwin/config.h
index dad6a350b..aede45f77 100644
--- a/winsup/cygwin/include/cygwin/config.h
+++ b/winsup/cygwin/include/cygwin/config.h
@@ -41,7 +41,7 @@ extern "C" {
 #else
 #include "../tlsoffsets.h"
 #endif
-__attribute__((gnu_inline))
+__attribute__((__gnu_inline__))
 extern inline struct _reent *__getreent (void)
 {
   register char *ret;
diff --git a/winsup/cygwin/include/cygwin/signal.h 
b/winsup/cygwin/include/cygwin/signal.h
index a8c852ddb..630afc817 100644
--- a/winsup/cygwin/include/cygwin/signal.h
+++ b/winsup/cygwin/include/cygwin/signal.h
@@ -46,7 +46,7 @@ struct _fpstate
   __uint32_t padding[24];
 };

-struct __attribute__ ((aligned (16))) __mcontext
+struct __attribute__ ((__aligned__ (16))) __mcontext
 {
   __uint64_t p1home;
   __uint64_t p2home;
diff --git a/winsup/cygwin/include/pthread.h b/winsup/cygwin/include/pthread.h
index 9e8eb6f2b..6d3bfd0eb 100644
--- a/winsup/cygwin/include/pthread.h
+++ b/winsup/cygwin/include/pthread.h
@@ -223,8 +223,8 @@ void pthread_testcancel (void);

 #if __GNU_VISIBLE
 int pthread_getattr_np (pthread_t, pthread_attr_t *);
-int pthread_getname_np (pthread_t, char *, size_t) __attribute__((nonnull(2)));
-int pthread_setname_np (pthread_t, const char *) __attribute__((nonnull(2)));
+int pthread_getname_np (pthread_t, char *, size_t) 
__attribute__((__nonnull__(2)));
+int pthread_setname_np (pthread_t, const char *) 
__attribute__((__nonnull__(2)));
 int pthread_sigqueue (pthread_t *, int, const union sigval);
 int pthread_yield (void);
 #endif
diff --git a/winsup/cygwin/include/sys/ucontext.h 
b/winsup/cygwin/include/sys/ucontext.h
index 8795476fc..58dc3874a 100644
--- a/winsup/cygwin/include/sys/ucontext.h
+++ b/winsup/cygwin/include/sys/ucontext.h
@@ -13,7 +13,7 @@ details. */

 typedef struct __mcontext mcontext_t;

-typedef __attribute__ ((aligned (16))) struct __ucontext {
+typedef __attribute__ ((__aligned__ (16))) struct __ucontext {
mcontext_t  uc_mcontext;
struct __ucontext *uc_link;
sigset_tuc_sigmask;
-- 
2.13.5

Re: stdnoreturn: fix for Cygwin

[Eric Blake]

Adding cygwin list...

On 08/16/2017 07:01 PM, Bruno Haible wrote:
> On Cygwin 1.7.30, I'm seeing this testdir build failure, when compiling
> test-stdnoreturn.c:
> 
> /usr/include/stdlib.h:66:28: error: expected ‘,’ or ‘;’ before ‘)’ token
>  _VOID _EXFUN(abort,(_VOID) _ATTRIBUTE ((noreturn)));

> +
> +   Similarly, on Cygwin, standard include files contain declarations like
> + void __cdecl abort (void) __attribute__ ((noreturn));
> +   "#define noreturn _Noreturn" would cause this declaration to be rewritten
> +   to the invalid
> + void __cdecl abort (void) __attribute__ ((__attribute__ 
> ((__noreturn__;

Hmm. It's evil for any system .h file to ever use
__attribute__((barename)), since barename is in the user's namespace and
can therefore be defined to anything else, possibly breaking the header
(as you just proved).  Hopefully, the problem goes away if cygwin
patches its headers to use __attribute__((__noreturn__)), so that gnulib
can then define noreturn at will.

I'll look into patching Cygwin to fix all barename attributes I can find
that should be __barename__ instead.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

missing poppler and openjpeg packages on mirrors

[Isaac Hanson]

It seems that some packages have recently gone missing from many
cygwin mirrors.  Specifically, I have noticed all the poppler and
openjpeg packages are gone, while still in the setup.ini and
dependencies of other packages.

setup.exe reports "HTTP status 404 fetching" and lists the URL to the
package, for example,
"http://cygwin.mirror.constant.com/x86_64/release/poppler/libpoppler66/libpoppler66-0.52.0-1.tar.xz;

Any help would be appreciated.

Isaac

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mailing list threads [was: gawk 4.1.4: CR separate char for CRLF files]

[Steven Penny]

On Wed, 16 Aug 2017 14:27:37, David Macek wrote:

Please stop breaking the message threads, it's hard to comprehend what's ha=
ppening this way.  If needed, I can help with configuring your e-mail clien=
t.


You really dont need to be giving people advice about their email client. Glass
houses and all that:

http://cygwin.com/ml/cygwin/2017-08/msg00116.html


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[newlib-cygwin] Add RISC-V port for newlib

[Jeff Johnston]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=363dbb9e44d0101f29ec34cadd001893daab3fc6

commit 363dbb9e44d0101f29ec34cadd001893daab3fc6
Author: Kito Cheng 
Date:   Thu Jul 27 16:44:22 2017 +0800

Add RISC-V port for newlib

  Contributor list:
- Andrew Waterman  
- Palmer Dabbelt  
- Kito Cheng  
- Scott Beamer  

Diff:
---
 COPYING.NEWLIB   |   13 +
 newlib/configure.host|9 +
 newlib/libc/include/machine/ieeefp.h |4 +
 newlib/libc/include/machine/setjmp.h |9 +
 newlib/libc/include/machine/time.h   |2 +-
 newlib/libc/include/sys/config.h |2 +-
 newlib/libc/machine/configure|3 +
 newlib/libc/machine/configure.in |1 +
 newlib/libc/machine/riscv/Makefile.am|   16 +
 newlib/libc/machine/riscv/Makefile.in|  491 +++
 newlib/libc/machine/riscv/aclocal.m4 | 1012 +++
 newlib/libc/machine/riscv/configure  | 4748 ++
 newlib/libc/machine/riscv/configure.in   |   14 +
 newlib/libc/machine/riscv/ffs.c  |   32 +
 newlib/libc/machine/riscv/ieeefp.c   |  110 +
 newlib/libc/machine/riscv/include/fenv.h |   42 +
 newlib/libc/machine/riscv/memcpy.c   |   81 +
 newlib/libc/machine/riscv/memset.S   |   98 +
 newlib/libc/machine/riscv/setjmp.S   |   98 +
 newlib/libc/machine/riscv/strcmp.S   |  148 +
 newlib/libc/machine/riscv/strcpy.c   |   64 +
 newlib/libc/machine/riscv/strlen.c   |   53 +
 newlib/libc/machine/riscv/sys/asm.h  |   50 +
 newlib/libc/machine/riscv/sys/fenv.h |   77 +
 newlib/libc/machine/riscv/sys/string.h   |   23 +
 25 files changed, 7198 insertions(+), 2 deletions(-)

diff --git a/COPYING.NEWLIB b/COPYING.NEWLIB
index 9b4c569..942c90a 100644
--- a/COPYING.NEWLIB
+++ b/COPYING.NEWLIB
@@ -1133,3 +1133,16 @@ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 
CAUSED AND ON ANY
 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+(49) - SiFive Inc. (riscv-* targets)
+
+Copyright (c) 2017  SiFive Inc. All rights reserved.
+
+This copyrighted material is made available to anyone wishing to use,
+modify, copy, or redistribute it subject to the terms and conditions
+of the BSD License.   This program is distributed in the hope that
+it will be useful, but WITHOUT ANY WARRANTY expressed or implied,
+including the implied warranties of MERCHANTABILITY or FITNESS FOR
+A PARTICULAR PURPOSE.  A copy of this license is available at
+http://www.opensource.org/licenses.
+
diff --git a/newlib/configure.host b/newlib/configure.host
index d471200..3d967a1 100644
--- a/newlib/configure.host
+++ b/newlib/configure.host
@@ -255,6 +255,12 @@ case "${host_cpu}" in
   powerpc*)
machine_dir=powerpc
;;
+  riscv*)
+   libm_machine_dir=riscv
+   machine_dir=riscv
+   newlib_cflags="${newlib_cflags}"
+   default_newlib_atexit_dynamic_alloc="no"
+   ;;
   rl78)
machine_dir=rl78
newlib_cflags="${newlib_cflags} -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY"
@@ -806,6 +812,9 @@ case "${host}" in
newlib_cflags="${newlib_cflags} -DHAVE_OPENDIR -DHAVE_RENAME 
-DHAVE_FCNTL -D_NO_POSIX_SPAWN"
syscall_dir=syscalls
;;
+  riscv*-*-*)
+   syscall_dir=syscalls
+   ;;
   sh*-*-*)
default_newlib_io_long_long="yes"
syscall_dir=syscalls
diff --git a/newlib/libc/include/machine/ieeefp.h 
b/newlib/libc/include/machine/ieeefp.h
index 11ef0dd..29c08fa 100644
--- a/newlib/libc/include/machine/ieeefp.h
+++ b/newlib/libc/include/machine/ieeefp.h
@@ -170,6 +170,10 @@
 #define __IEEE_LITTLE_ENDIAN
 #endif
 
+#ifdef __riscv
+#define __IEEE_LITTLE_ENDIAN
+#endif
+
 #ifdef __i960__
 #define __IEEE_LITTLE_ENDIAN
 #endif
diff --git a/newlib/libc/include/machine/setjmp.h 
b/newlib/libc/include/machine/setjmp.h
index e6c3142..b33f437 100644
--- a/newlib/libc/include/machine/setjmp.h
+++ b/newlib/libc/include/machine/setjmp.h
@@ -358,6 +358,15 @@ _BEGIN_STD_C
 #define _JBLEN 12
 #endif
 
+#ifdef __riscv
+#define _JBTYPE long
+#ifdef __riscv_32e
+#define _JBLEN ((4*sizeof(long))/sizeof(long))
+#else
+#define _JBLEN ((14*sizeof(long) + 12*sizeof(double))/sizeof(long))
+#endif
+#endif
+
 #ifdef _JBLEN
 #ifdef _JBTYPE
 typedef_JBTYPE jmp_buf[_JBLEN];
diff --git a/newlib/libc/include/machine/time.h 
b/newlib/libc/include/machine/time.h
index 6f9a35c..c75edaf 100644
--- a/newlib/libc/include/machine/time.h
+++ b/newlib/libc/include/machine/time.h
@@ -1,7 +1,7 @@
 #ifndef_MACHTIME_H_
 #define_MACHTIME_H_
 
-#if defined(__rtems__) || defined(__VISIUM__)
+#if defined(__rtems__) || defined(__VISIUM__) || defined(__riscv)
 #define 

REVISITED: Signal delivered while blocked

[Houder]

Hi,

Please read this post first:

https://cygwin.com/ml/cygwin/2017-08/msg00048.html
( Signal delivered while blocked -- by Noah Misch, August 4th 2017 )

This post is not intended to "hijack" the post by Noah Misch; this post 
only
ships an alternative (i.e. revised) testcase for the one by provided by 
Noah

Misch.

The alternative testcase in fact consists of 2 testcases (2 files):

 1. sigprocmask-exclusion4.c
 2. sigprocmask-exclusion5.c

The 1st testcase uses sigaction() (i.c. sa_mask) in order to keep both 
signal

handlers "out of each other's hair".

The 2nd testcase achieves this by protecting the "vital part" of each of 
the

signal handlers using sigprocmask() ...

Using sigprocmask() and SIG_BLOCK (1st argument), the other signal is 
added
to the signal mask at the start of the "vital part" of the signal 
handler.


To restore the signal mask at the end of the "vital part" of the 
handler, it

is possible to choose between the following options:

 a. using sigprocmask() and SIG_SETMASK in order to reinstate the mask 
as it

was at the beginning of the "vital part" of the handler

 b. using sigprocmask() and SIG_UNBLOCK to remove the other signal from 
the

signal mask

Both testcases confirm that Cygwin _sometimes_ delivers a signal, 
although

the signal mask specifies (verified by the test case) it should not.

Typical runs:

64-@@ ./sigprocmask-exclusion4
-
pid=2728 inundating pid=3504 with SIGUSR1 and SIGCHLD
--
ERROR: handler2: No 1 running
cnt_usr1 = 424, cnt_chld = 305, cnt_int = 0
ERROR: handler2: No 1 running
cnt_usr1 = 1212, cnt_chld = 1262, cnt_int = 0
ERROR: handler: No 2 running
cnt_usr1 = 4341, cnt_chld = 3827, cnt_int = 0
ERROR: handler: No 2 running
cnt_usr1 = 5289, cnt_chld = 4171, cnt_int = 0
ERROR: handler: No 2 running
cnt_usr1 = 5499, cnt_chld = 4354, cnt_int = 0
ERROR: handler: No 2 running
cnt_usr1 = 6769, cnt_chld = 6295, cnt_int = 0
ERROR: handler2: nesting self!
cnt_usr1 = 10463, cnt_chld = 9243, cnt_int = 0
ERROR: handler2: nesting self!
cnt_usr1 = 12390, cnt_chld = 10869, cnt_int = 0
ERROR: handler: No 2 running
cnt_usr1 = 14046, cnt_chld = 14771, cnt_int = 0
ERROR: handler2: No 1 running
cnt_usr1 = 16111, cnt_chld = 15785, cnt_int = 0
cnt_usr1 = 16959, cnt_chld = 16790, cnt_int = 1
child done
xcnt_usr1 = 13295798, xcnt_chld = 13295797

64-@@

64-@@ ./sigprocmask-exclusion5
-
--
pid=4132 inundating pid=5976 with SIGUSR1 and SIGCHLD
ERROR: handler: No 2 running
cnt_usr1 = 1, cnt_chld = 2, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 228, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 1444, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 1585, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 1830, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 2588, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 2719, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 2795, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 3332, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 3340, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 3353, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 4130, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 4136, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 5256, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 6548, cnt_chld = 6, cnt_int = 0
ERROR: handler: nesting self!
cnt_usr1 = 8292, cnt_chld = 6, cnt_int = 0
cnt_usr1 = 11223, cnt_chld = 6, cnt_int = 1
child done
xcnt_usr1 = 4149717, xcnt_chld = 4149717

64-@@

Both runs were terminated by SIGINT (^C).

When running for an extended period (hours), the run-away stack did not 
show

up (Linux).

Environment:

64-@@ uname -a
CYGWIN_NT-6.1 Seven 2.9.0(0.316/5/3)  x86_64 Cygwin
64-@@ gcc --version
gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE


Regards,

Henri// gcc -std=c11 -D_POSIX_SOURCE -o sigprocmask-exclusion sigprocmask-exclusion.c
// gcc -std=c11 -D_DEFAULT_SOURCE -o sigprocmask-exclusion sigprocmask-exclusion.c

/* ... cfm 2
 kopie van origineel
 gewijzigd:
  - forbid, permit verwijderd (forbid en permit opgenomen in main() )
  - handlers: geen bewerking van het signal mask
  - sigaction: het andere signal wordt verhinderd
 this test case fails on Cygwin; period!
 */

/*
 * Demonstrate improper delivery of a blocked signal.
 *
 * This program prints "ERROR: already forbidden" and aborts within one
 * second on this configuration (uname -srvm):
 *   CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64
 *
 * It runs indefinitely (>600s) without trouble on these configurations:
 *   CYGWIN_NT-6.0 1.7.27(0.271/5/3) 2013-12-09 11:57 i686
 *   Linux 

Re: Current timestamp

[Jon Turney]

On 16/08/2017 19:26, David Stacey wrote:

On 16/08/17 15:35, Ugly Leper wrote:

Looked at several mirror sites just this minute (1435 GMT Aug 16).
All showing setup.ini with setup-timestamp 1502381207 (Aug 10) whereas
most recent update seems to have been stamped 1502735714 (Aug 14).


This appears to be affecting x86 only, where setup.ini is timestamped 
2017-08-10. For x86_64, setup.ini is dated 2017-08-14.


This isn't a mirroring issue, as I'm seeing this on sourceware.

Jon: Is calm running correctly for x86?


sourceware.org is having some fallout from a hardware upgrade (see [1]).

Some things got restored from backup.  Work is ongoing.

[1] https://www.sourceware.org/ml/overseers/2017-q3/msg00060.html

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Current timestamp

[David Stacey]

On 16/08/17 15:35, Ugly Leper wrote:

Looked at several mirror sites just this minute (1435 GMT Aug 16).
All showing setup.ini with setup-timestamp 1502381207 (Aug 10) whereas
most recent update seems to have been stamped 1502735714 (Aug 14).


This appears to be affecting x86 only, where setup.ini is timestamped 
2017-08-10. For x86_64, setup.ini is dated 2017-08-14.


This isn't a mirroring issue, as I'm seeing this on sourceware.

Jon: Is calm running correctly for x86?

Dave.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Current timestamp

[Ugly Leper]

Looked at several mirror sites just this minute (1435 GMT Aug 16).
All showing setup.ini with setup-timestamp 1502381207 (Aug 10) whereas
most recent update seems to have been stamped 1502735714 (Aug 14).

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gawk 4.1.4: CR separate char for CRLF files

[cyg Simple]

Vermessung AVT - Wolfgang Rieger writes:

> 5) You can always find a better way to do things, of course, I won't
> argue about that. Sometimes we thought about switching to Java or php
> or python or whatever. Maybe, we should. But we have a lot of running
> scripts, massive batch and parallel processing, and cmd.exe with
> minimum Cygwin (no X subsystem, no pile of tools, just a tiny
> installation) has worked great for many years - so why not use it?
> Just because it is not intended to use it that way?

Just because it is not intended to use it that way, yes, that is the
reason not to do it.  Just because it works now doesn't mean that it
will continue to work and you put yourself in jeopardy if you ever
update your software.  With your use of cmd.exe instead of a Cygwin
shell also puts you at risk of not being able to execute your scripts.
While Cygwin doesn't intentionally cause its binaries to not execute
outside of Cygwin support for those binaries is only supported if the
problems exist within the Cygwin shell as well.  So if an executable
provides expected results in bash but not in cmd, you lose.

-- 
cyg Simple

P.S.: You need to learn how to use a proper mail client and respond to
this list appropriately.  I had to "edit as new" and hand edit the mail
just to get proper quoting.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Mailing list threads [was: gawk 4.1.4: CR separate char for CRLF files]

[David Macek]

Please stop breaking the message threads, it's hard to comprehend what's 
happening this way.  If needed, I can help with configuring your e-mail client.

--
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

Re: gawk 4.1.4: CR separate char for CRLF files

[Eric Blake]

On 08/16/2017 07:09 AM, Vermessung AVT - Wolfgang Rieger wrote:
> Achim Gratz wrote:
> Vermessung AVT - Wolfgang Rieger writes:
>> Another solution which we have been using for many years now, though 
>> it might not be feasible for you:
> Cygwin is, like it or not, a rolling distribution.

Your quoting is horrible; you repeated Achim's comments without adding
any '>' nesting,


> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Then used a '-- ' line, which sane mail clients treat as the end of the
email and start of the signature, and only then added your content.
Thunderbird, in particular, refuses to include signatures by default
when replying to a message; and hitting 'ctrl-a' then reply to at least
paste all of your text then loses the formatting of your message, making
it very difficult to reply to you, as shown here:

> SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
> http://Synth.Stromeko.net/Downloads.html#KorgSDada Dear Achim, I fully
> agree to most of what you say. But: 1) As well as Cygwin is a rolling
> distrib my work is a "rolling work". And that is why I deal with it in

At any rate, in answer to your question:

> 
> Anyway, thanks for the suggestion to contact the upstream developers. I was 
> not aware of that. Can you give me a hint where to go?

awk --help | tail -n10

points you to the manual for how to report upstream bugs; if you don't
like info, the same data can be found here:

https://www.gnu.org/software/gawk/manual/html_node/Bugs.html#Bugs

(in general, ANY good program will include instructions for how to reach
upstream in its --help output - of course, not all programs are at the
same level of goodness in this regards)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: gawk 4.1.4: CR separate char for CRLF files

[Vermessung AVT - Wolfgang Rieger]

Achim Gratz wrote:
Vermessung AVT - Wolfgang Rieger writes:
> Another solution which we have been using for many years now, though 
> it might not be feasible for you:

- snip 

Jannick, another idea I had thought of previously might eventually help:

There is the possibility in awk to include source code by @include "myfile.awk" 
syntax. I was sometimes thinking of providing a general awk script that could 
deal with oddities of any kind that could easily be changed just in myfile.awk 
when necessary, e.g. due to updates. You could even think of an optional 
environment variable to control which script to include. It should be easy to 
add such an @include line in all gawk scripts automatically. Did you thing of 
something like that?

Kind regards,
Wolfgang


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gawk 4.1.4: CR separate char for CRLF files

[Vermessung AVT - Wolfgang Rieger]

Achim Gratz wrote:
Vermessung AVT - Wolfgang Rieger writes:
> Another solution which we have been using for many years now, though 
> it might not be feasible for you:

Cygwin is, like it or not, a rolling distribution.

> We very rarely update Cygwin. We have been using Cygwin for some 15+ 
> years now. We use tools like gawk (hundreds of scripts), head, tail, 
> sort, etc. that we are using in shell scripts running under cmd.exe 
> (no Unix shells involved). I soon realized that upgrades of Cygwin may 
> cause troubles with existing scripts, so we only update if we really 
> need to (e.g.: New functionality that would be important, 32 to 64 bit 
> shift, eventually new Windows versions, bugs we needed to be fixed).

Hopefully the machine(s) runnning those scripts are isolated.

In your particular case you might be better off using MSys2 or GNUwin32 tools, 
although you'd still need a better way to deal with updates.
Also, audit your scripts for non-portable constructs, since those are the parts 
that most likely to break.  CMD scripting is a tough nut to crack if it's of 
any complexity and there are lots of things that are poorly or not officially 
documented.  I don't quite understand why you use POSIX tools, but specifically 
shun POSIX scripting.

> I have followed the discussions about the CR/LF behaviour changes in 
> the past attentively and decided not to update in near future, because 
> that would lead to a massive problem with many hundreds of scripts - 
> hoping that sometimes there will be a change in gawk again.

You'd better replace that hope with a feature request at gawk upstream.

> What is Unix-like or OS-like or Posix-like behaviour in that context?
> You could argue that gawk interprets line endings like the underlying 
> OS does (i. e., gawk reads LF in Unix and CR/LF in Win), or it 
> interprets line endings in a Unix-style no matter of the underlying OS 
> used. That's a developer's decision in my opinion.

Cygwin uses LF line endings (yes there are still text mounts, but you'd be 
better off pretending they don't exist).  When you're trying to use it for CRLF 
files, you need to wrap those invocations to do an explicit conversion.

https://cygwin.com/cygwin-ug-net/using-textbinary.html

> But since with pipes or output redirection gawk used to write no CRs 
> even in previous versions, we already had the problem that gawk had to 
> accept *both* inputs, LF with or without CR. That worked widely fine 
> so far, since most Windows and other application SW we use accept both 
> record formats, fortunately (we had issues with SW upgrades of other 
> vendors no longer accepting pure LF, but that only concerned a very 
> small number of scripts). With the new approach in Cygwin that seems 
> to be broken, so we did not upgrade Cygwin since then (we currently 
> use gawk 4.1.3).

Again, your attempt to freeze your system at some arbitrary point in time is 
misguided.  It'll never quite work out and chances are that when it breaks it 
will do so in ways that creates more work and forces you to do it in emergency 
mode, which is never a good thing.

> Of course the reason for that really annoying CR/LF thing is the 
> arrogance and ignorance of MS, which caused innumerable of useless 
> developers' hours when I think of the endless discussions and changes 
> in Cygwin; but MS is the one who defines the standards because of its 
> very market power, so we have to deal with it, if we like or not.

You really can't blame them for CRLF, they weren't and aren't the only ones 
using it and it's been in use long before Microsoft entered the scene.

> I'd definitely prefer to use Unix for its powerful tools, but most of 
> the SW we use is simply not available for Unix, and MS does not 
> provide gawk etc. So we have to deal with that CR/LF issue in a 
> pragmatic rather than in a more, say, philosophical approach: We need 
> to run our scripts with as little changes as possible. So that's why 
> we upgrade Cygwin as seldom as possible. It is a "living system", yes, 
> which is great on the one side - but can be annoying in everyday 
> practice.

Again, you'd better figure out how to transform your input (and possibly
output) so it'll conform to the conventions of the tool(s) you use, perhaps by 
providing a handful of wrapper scripts.  Alternatively, only use tools that 
adhere to the same set of conventions.

> In my opinion there should be at least an option for gawk to accept 
> both LF and CR/LF line endings equally, preferably with a system 
> variable so that there is no need to change the command line call of 
> gawk at all. That's what I vote for.

Yes, but please cast that vote with the upstream developers.  I reckon it'd be 
a generally useful function, so there's no point in providing it only on Cygwin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:

libpoppler-devel issue

[Bastian Germann]

When I built gambas3-gb-pdf-3.10.0-1 I noticed an issue with the x86_64
version of libpoppler-devel-0.52.0-1.

usr/lib/libpoppler.dll.a could not be linked, because autoconf's file
test based on a magic gave an error. Then I checked with "file
/usr/lib/libpoppler.dll.a" and it gave a different output than all the
other *.dll.a files.

I built the package from source as a "solution", but wanted to share
this issue for further investigation.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple