date:20200518

[PATCH 2/3] Cygwin: tzcode resync v2: imports

2020-05-18 Thread Mark Geisert

Import most recent NetBSD localtime.c, private.h, and tzfile.h.

---
 winsup/cygwin/tzcode/localtime.c | 2493 ++
 winsup/cygwin/tzcode/private.h   |  795 ++
 winsup/cygwin/tzcode/tzfile.h|  174 +++
 3 files changed, 3462 insertions(+)
 create mode 100644 winsup/cygwin/tzcode/localtime.c
 create mode 100644 winsup/cygwin/tzcode/private.h
 create mode 100644 winsup/cygwin/tzcode/tzfile.h

diff --git a/winsup/cygwin/tzcode/localtime.c b/winsup/cygwin/tzcode/localtime.c
new file mode 100644
index 0..a4d02a4c7
--- /dev/null
+++ b/winsup/cygwin/tzcode/localtime.c
@@ -0,0 +1,2493 @@
+/* $NetBSD: localtime.c,v 1.122 2019/07/03 15:50:16 christos Exp $ */
+
+/* Convert timestamp from time_t to struct tm.  */
+
+/*
+** This file is in the public domain, so clarified as of
+** 1996-06-05 by Arthur David Olson.
+*/
+
+#include 
+#if defined(LIBC_SCCS) && !defined(lint)
+#if 0
+static charelsieid[] = "@(#)localtime.c8.17";
+#else
+__RCSID("$NetBSD: localtime.c,v 1.122 2019/07/03 15:50:16 christos Exp $");
+#endif
+#endif /* LIBC_SCCS and not lint */
+
+/*
+** Leap second handling from Bradley White.
+** POSIX-style TZ environment variable handling from Guy Harris.
+*/
+
+/*LINTLIBRARY*/
+
+#include "namespace.h"
+#include 
+#define LOCALTIME_IMPLEMENTATION
+#include "private.h"
+
+#include "tzfile.h"
+#include 
+
+#if NETBSD_INSPIRED
+# define NETBSD_INSPIRED_EXTERN
+#else
+# define NETBSD_INSPIRED_EXTERN static
+#endif
+
+#if defined(__weak_alias)
+__weak_alias(daylight,_daylight)
+__weak_alias(tzname,_tzname)
+#endif
+
+#ifndef TZ_ABBR_MAX_LEN
+#define TZ_ABBR_MAX_LEN16
+#endif /* !defined TZ_ABBR_MAX_LEN */
+
+#ifndef TZ_ABBR_CHAR_SET
+#define TZ_ABBR_CHAR_SET \
+   "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 :+-._"
+#endif /* !defined TZ_ABBR_CHAR_SET */
+
+#ifndef TZ_ABBR_ERR_CHAR
+#define TZ_ABBR_ERR_CHAR   '_'
+#endif /* !defined TZ_ABBR_ERR_CHAR */
+
+/*
+** SunOS 4.1.1 headers lack O_BINARY.
+*/
+
+#ifdef O_BINARY
+#define OPEN_MODE  (O_RDONLY | O_BINARY | O_CLOEXEC)
+#endif /* defined O_BINARY */
+#ifndef O_BINARY
+#define OPEN_MODE  (O_RDONLY | O_CLOEXEC)
+#endif /* !defined O_BINARY */
+
+#ifndef WILDABBR
+/*
+** Someone might make incorrect use of a time zone abbreviation:
+** 1.  They might reference tzname[0] before calling tzset (explicitly
+** or implicitly).
+** 2.  They might reference tzname[1] before calling tzset (explicitly
+** or implicitly).
+** 3.  They might reference tzname[1] after setting to a time zone
+** in which Daylight Saving Time is never observed.
+** 4.  They might reference tzname[0] after setting to a time zone
+** in which Standard Time is never observed.
+** 5.  They might reference tm.TM_ZONE after calling offtime.
+** What's best to do in the above cases is open to debate;
+** for now, we just set things up so that in any of the five cases
+** WILDABBR is used. Another possibility: initialize tzname[0] to the
+** string "tzname[0] used before set", and similarly for the other cases.
+** And another: initialize tzname[0] to "ERA", with an explanation in the
+** manual page of what this "time zone abbreviation" means (doing this so
+** that tzname[0] has the "normal" length of three characters).
+*/
+#define WILDABBR   "   "
+#endif /* !defined WILDABBR */
+
+static const char  wildabbr[] = WILDABBR;
+
+static const char  gmt[] = "GMT";
+
+/*
+** The DST rules to use if TZ has no rules and we can't load TZDEFRULES.
+** Default to US rules as of 2017-05-07.
+** POSIX does not specify the default DST rules;
+** for historical reasons, US rules are a common default.
+*/
+#ifndef TZDEFRULESTRING
+#define TZDEFRULESTRING ",M3.2.0,M11.1.0"
+#endif
+
+struct ttinfo {/* time type information */
+   int_fast32_ttt_utoff;   /* UT offset in seconds */
+   booltt_isdst;   /* used to set tm_isdst */
+   int tt_desigidx;/* abbreviation list index */
+   booltt_ttisstd; /* transition is std time */
+   booltt_ttisut;  /* transition is UT */
+};
+
+struct lsinfo {/* leap second information */
+   time_t  ls_trans;   /* transition time */
+   int_fast64_tls_corr;/* correction to apply */
+};
+
+#define SMALLEST(a, b) (((a) < (b)) ? (a) : (b))
+#define BIGGEST(a, b)  (((a) > (b)) ? (a) : (b))
+
+#ifdef TZNAME_MAX
+#define MY_TZNAME_MAX  TZNAME_MAX
+#endif /* defined TZNAME_MAX */
+#ifndef TZNAME_MAX
+#define MY_TZNAME_MAX  255
+#endif /* !defined TZNAME_MAX */
+
+#define state __state
+struct state {
+   int leapcnt;
+   int timecnt;
+   int typecnt;
+   int charcnt;
+   boolgoback;
+   boolgoahead;
+   time_t

[PATCH 0/3] Cygwin: tzcode resync v2

2020-05-18 Thread Mark Geisert

This is a reorganization of the previous patch contents to cut down on
extraneous material.  It seems to be complete and could thus be applied
to a copy of the newlib-cygwin tree successfully for testing or review.

Methods of testing can be discussed by reply to this post, or on
cygwin-developers, whichever is most appropriate.  I'm also open to other
strategies of implementation if this one seems risky or unattractive for
some reason.

..mark

[PATCH 1/3] Cygwin: tzcode resync v2: basics
[PATCH 2/3] Cygwin: tzcode resync v2: imports
[PATCH 3/3] Cygwin: tzcode resync v2: details

[PATCH 3/3] Cygwin: tzcode resync v2: details

2020-05-18 Thread Mark Geisert

Add tz_posixrules.h with data generated from most recent Cygwin tzdata
package.  Establish localtime.cc as primarily a wrapper around a patched
copy of localtime.c.  See README for more information.

---
 winsup/cygwin/tzcode/README|  37 +++
 winsup/cygwin/tzcode/localtime.c.patch | 399 +
 winsup/cygwin/tzcode/localtime.cc  | 159 ++
 winsup/cygwin/tzcode/tz_posixrules.h   | 231 ++
 4 files changed, 826 insertions(+)
 create mode 100644 winsup/cygwin/tzcode/README
 create mode 100644 winsup/cygwin/tzcode/localtime.c.patch
 create mode 100644 winsup/cygwin/tzcode/localtime.cc
 create mode 100644 winsup/cygwin/tzcode/tz_posixrules.h

diff --git a/winsup/cygwin/tzcode/README b/winsup/cygwin/tzcode/README
new file mode 100644
index 0..dd01ac565
--- /dev/null
+++ b/winsup/cygwin/tzcode/README
@@ -0,0 +1,37 @@
+/*
+   How the code in this directory is supposed to work...
+   2020/05/13 Mark Geisert 
+
+   localtime.cc is the Cygwin-specific module that is compiled into
+   the Cygwin DLL when the latter is built.  It's just a wrapper that
+   #defines a bunch of stuff then #includes localtime.c.
+
+   localtime.c, at any point in time, is a reasonably recent version
+   of /src/lib/libc/time/localtime.c from NetBSD.  The same goes for
+   private.h and tzfile.h.
+
+   The idea is that in the future, one just needs to bring over newer
+   versions of localtime.c, private.h, and/or tzfile.h from NetBSD as
+   they become available.
+
+   With luck, you can drop those files into this directory and they
+   can be immediately used to build a newer Cygwin DLL that has the
+   newer NetBSD functionality.  Without luck, you'll have to tweak the
+   wrapper localtime.cc.  In the worst case, some other strategy will
+   need to be figured out, such as manually pulling out the parts of
+   the NetBSD code Cygwin needs to build a stand-alone localtime.cc.
+
+   Re tz_posixrules.h: The data elements can be generated from
+   /usr/share/zoneinfo/posixrules in any version of Cygwin's tzdata
+   package.  Instructions are in the comment leading tz_posixrules.h.
+
+   Addendum:
+   Implementation of the strategy above has uncovered a small number
+   of NetBSD-isms in localtime.c that cannot be worked around with
+   preprocessor tricks.  So there is another file localtime.c.patched
+   that holds just these adjustments for Cygwin, and it's this file
+   that localtime.cc #includes.  localtime.c.patched is generated by
+   winsup/cygwin/Makefile[.in] operating with localtime.c.patch.
+
+   ..mark
+*/
diff --git a/winsup/cygwin/tzcode/localtime.c.patch 
b/winsup/cygwin/tzcode/localtime.c.patch
new file mode 100644
index 0..a17d9ee90
--- /dev/null
+++ b/winsup/cygwin/tzcode/localtime.c.patch
@@ -0,0 +1,399 @@
+*** localtime.c2020-05-16 21:54:00.533111800 -0700
+--- localtime.c.patched2020-05-16 22:42:40.486924300 -0700
+***
+*** 1,3 
+--- 1,4 
++ // localtime.c.patched: based on NetBSD's localtime.c version 1.122
+  /*   $NetBSD: localtime.c,v 1.122 2019/07/03 15:50:16 christos Exp $ */
+  
+  /* Convert timestamp from time_t to struct tm.  */
+***
+*** 23,29 
+  
+  /*LINTLIBRARY*/
+  
+- #include "namespace.h"
+  #include 
+  #define LOCALTIME_IMPLEMENTATION
+  #include "private.h"
+--- 24,29 
+***
+*** 182,188 
+  
+  
+  #if !defined(__LIBC12_SOURCE__)
+! timezone_t __lclptr;
+  #ifdef _REENTRANT
+  rwlock_t __lcl_lock = RWLOCK_INITIALIZER;
+  #endif
+--- 182,188 
+  
+  
+  #if !defined(__LIBC12_SOURCE__)
+! static timezone_t __lclptr;
+  #ifdef _REENTRANT
+  rwlock_t __lcl_lock = RWLOCK_INITIALIZER;
+  #endif
+***
+*** 198,204 
+  
+  static struct tm tm;
+  
+! #if !HAVE_POSIX_DECLS || TZ_TIME_T || defined(__NetBSD__)
+  # if !defined(__LIBC12_SOURCE__)
+  
+  __aconst char *  tzname[2] = {
+--- 198,204 
+  
+  static struct tm tm;
+  
+! #if !HAVE_POSIX_DECLS || TZ_TIME_T || defined(__NetBSD__) || 
defined(__CYGWIN__)
+  # if !defined(__LIBC12_SOURCE__)
+  
+  __aconst char *  tzname[2] = {
+***
+*** 413,419 
+  };
+  
+  /* TZDIR with a trailing '/' rather than a trailing '\0'.  */
+! static char const tzdirslash[sizeof TZDIR] = TZDIR "/";
+  
+  /* Local storage needed for 'tzloadbody'.  */
+  union local_storage {
+--- 413,420 
+  };
+  
+  /* TZDIR with a trailing '/' rather than a trailing '\0'.  */
+! static char const tzdirslash[] = TZDIR "/";
+! #define sizeof_tzdirslash (sizeof tzdirslash - 1)
+  
+  /* Local storage needed for 'tzloadbody'.  */
+  union local_storage {
+***
+*** 428,434 
+  
+   /* The file name to be opened.  */
+   char fullname[/*CONSTCOND*/BIGGEST(sizeof (struct file_analysis),
+!  sizeof tzdirslash + 1024)];
+  };
+  
+  /* Load

[PATCH 1/3] Cygwin: tzcode resync v2: basics

2020-05-18 Thread Mark Geisert

Modifies winsup/cygwin/Makefile.in to build localtime.o from items in
new winsup/cygwin/tzcode subdirectory.  Removes existing localtime.cc
and tz_posixrules.h from winsup/cygwin as they are superseded by the
following patches.

---
 winsup/cygwin/Makefile.in |   12 +-
 winsup/cygwin/localtime.cc| 2597 -
 winsup/cygwin/tz_posixrules.h |   48 -
 3 files changed, 10 insertions(+), 2647 deletions(-)
 delete mode 100644 winsup/cygwin/localtime.cc
 delete mode 100644 winsup/cygwin/tz_posixrules.h

diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index f273ba793..59434a930 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -27,7 +27,7 @@ export CCWRAP_HEADERS:=. ${srcdir}
 export CCWRAP_SYSTEM_HEADERS:=@cygwin_headers@ @newlib_headers@
 export CCWRAP_DIRAFTER_HEADERS:=@windows_headers@
 
-VPATH+=$(srcdir)/regex $(srcdir)/lib $(srcdir)/libc $(srcdir)/math
+VPATH+=$(srcdir)/regex $(srcdir)/lib $(srcdir)/libc $(srcdir)/math 
$(srcdir)/tzcode
 
 target_cpu:=@target_cpu@
 target_alias:=@target_alias@
@@ -246,6 +246,14 @@ MATH_OFILES:= \
tgammal.o \
truncl.o
 
+TZCODE_OFILES:=localtime.o
+
+localtime.o: $(srcdir)/tzcode/localtime.cc $(srcdir)/tzcode/localtime.c.patch
+   (cd $(srcdir)/tzcode && \
+   patch -c -o localtime.c.patched localtime.c localtime.c.patch)
+   $(CXX) ${CXXFLAGS} -I$(target_builddir)/winsup/cygwin \
+   -I$(srcdir) -I$(srcdir)/tzcode -c -o $@ $<
+
 DLL_OFILES:= \
advapi32.o \
aio.o \
@@ -333,7 +341,6 @@ DLL_OFILES:= \
ldap.o \
libstdcxx_wrapper.o \
loadavg.o \
-   localtime.o \
lsearch.o \
malloc_wrapper.o \
minires-os-if.o \
@@ -412,6 +419,7 @@ DLL_OFILES:= \
$(EXTRA_OFILES) \
$(MALLOC_OFILES) \
$(MATH_OFILES) \
+   $(TZCODE_OFILES) \
$(MT_SAFE_OBJECTS)
 
 EXCLUDE_STATIC_OFILES:=$(addprefix --exclude=,\
diff --git a/winsup/cygwin/localtime.cc b/winsup/cygwin/localtime.cc
deleted file mode 100644
index 010376637..0
--- a/winsup/cygwin/localtime.cc
+++ /dev/null
@@ -1,2597 +0,0 @@
-/* $NetBSD: localtime.c,v 1.72 2012/10/28 19:02:29 christos Exp $  */
-
-/* Don't reformat the code arbitrarily.
-
-   It uses in wide parts the exact formatting as the upstream NetBSD
-   versions.  The purpose is to simplify subsequent diffs to the NetBSD
-   version, should the need arise again at one point. */
-
-/*
-** This file is in the public domain, so clarified as of
-** 1996-06-05 by Arthur David Olson.
-*/
-/* Temporarily merged private.h and tzfile.h for ease of management - DJ */
-
-#include "winsup.h"
-#include "cygerrno.h"
-#include "sync.h"
-#include 
-#define STD_INSPIRED
-#define lint
-
-#define USG_COMPAT
-
-#ifndef lint
-#ifndef NOID
-static charelsieid[] = "@(#)localtime.c8.17";
-#endif /* !defined NOID */
-#endif /* !defined lint */
-
-/*
-** Leap second handling from Bradley White.
-** POSIX-style TZ environment variable handling from Guy Harris.
-*/
-
-#define NO_ERROR_IN_DST_GAP
-
-/*LINTLIBRARY*/
-
-#ifndef PRIVATE_H
-
-#define PRIVATE_H
-
-/*
-** This file is in the public domain, so clarified as of
-** 1996-06-05 by Arthur David Olson
-*/
-
-/*
-** This header is for use ONLY with the time conversion code.
-** There is no guarantee that it will remain unchanged,
-** or that it will remain at all.
-** Do NOT copy it to any system include directory.
-** Thank you!
-*/
-
-/*
-** ID
-*/
-
-#ifndef lint
-#ifndef NOID
-static charprivatehid[] = "@(#)private.h   7.48";
-#endif /* !defined NOID */
-#endif /* !defined lint */
-
-/*
-** Nested includes
-*/
-
-#include "stdio.h"
-#include "limits.h"/* for CHAR_BIT */
-#include "stdlib.h"
-#include "unistd.h"/* for F_OK and R_OK */
-
-/* Unlike 's isdigit, this also works if c < 0 | c > UCHAR_MAX.  */
-#define is_digit(c) ((unsigned)(c) - '0' <= 9)
-
-#ifndef __pure
-#if 2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__)
-# define __pure __attribute__ ((__pure__))
-#else
-# define __pure /* empty */
-#endif
-#endif
-
-/*
-** Finally, some convenience items.
-*/
-
-#ifndef TYPE_INTEGRAL
-#define TYPE_INTEGRAL(type) (/*CONSTCOND*/((type) 0.5) != 0.5)
-#endif /* !defined TYPE_INTEGRAL */
-
-#ifndef TYPE_BIT
-#define TYPE_BIT(type) (sizeof (type) * CHAR_BIT)
-#endif /* !defined TYPE_BIT */
-
-#ifndef TYPE_SIGNED
-#define TYPE_SIGNED(type) (((type) -1) < 0)
-#endif /* !defined TYPE_SIGNED */
-
-#ifndef INT_STRLEN_MAXIMUM
-/*
-** 302 / 1000 is log10(2.0) rounded up.
-** Subtract one for the sign bit if the type is signed;
-** add one for integer division truncation;
-** add one more for a minus sign if the type is signed.
-*/
-#define INT_STRLEN_MAXIMUM(type) \
-((TYPE_BIT(type) - TYPE_SIGNED(type)) * 302 / 1000 + 1 + TYPE_SIGNED(type))
-#endif /* !defined INT_STRLEN_MAXIMUM */
-
-/*
-** INITIALIZE(x)
-*/
-
-#ifndef GNUC_or_lint
-#ifdef lint
-#define GNUC_or_lint
-#endif /* defined lint */

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread Chris Wagner


On 2020-05-18 8:40 am, jeff wrote:

I have a directory that has some files with odd files.
I can do a 'ls', successfully. However if I do a 'ls *'' I get:
ls: cannot access '*': No such file or directory

Here is ls output:
'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'
'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'



I can confirm this.  I've seen weirdo behavior before with Cygwin 
commands having to interpret wild cards internally.  It's probably 
related to some wonky unicode optimization or incomplete wildcard 
implementation.  This falls under the category of "don't do that". :)



Mintty:
$ uname -a; cygcheck -c coreutils
CYGWIN_NT-6.1 applejack 3.1.0(0.340/5/3) 2019-11-19 13:58 x86_64 Cygwin
Cygwin Package Information
Package  VersionStatus
coreutils8.26-2 OK

wagnerc@applejack /tmp/wild
$ touch 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'; dir *
-rw-rw-r--+ 1 0 May 18 21:46 foo
-rw-rw-r--+ 1 0 May 18 21:55 Highlander-S03E21-Finalé_Part_I-22.mkv


CMD:
C:\cygwin64\tmp\wild>dir
 Volume in drive C is INTELWINNT
 Volume Serial Number is 642B-E7BA

 Directory of C:\cygwin64\tmp\wild

05/18/2020  09:46 PM  .
05/18/2020  09:46 PM  ..
05/18/2020  09:46 PM 0 foo
05/18/2020  09:55 PM 0 
Highlander-S03E21-Finalé_Part_I-22.mkv

   2 File(s)  0 bytes
   2 Dir(s)  35,887,038,464 bytes free

C:\cygwin64\tmp\wild>ls
'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'   foo

C:\cygwin64\tmp\wild>ls *
ls: cannot access '*': No such file or directory

C:\cygwin64\tmp\wild>ls f*
foo

C:\cygwin64\tmp\wild>ls H*
ls: cannot access 'H*': No such file or directory



Thanks.





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

Re: [PATCH 00/21] FIFO: Support multiple readers

2020-05-18 Thread Takashi Yano via Cygwin-patches

Hi Ken,

On Mon, 18 May 2020 13:42:19 -0400
Ken Brown via Cygwin-patches  wrote:
> Hi Takashi,
> 
> On 5/18/2020 12:03 PM, Ken Brown via Cygwin-patches wrote:
> > On 5/18/2020 1:36 AM, Takashi Yano via Cygwin-patches wrote:
> >> On Mon, 18 May 2020 14:25:19 +0900
> >> Takashi Yano via Cygwin-patches  wrote:
> >>> However, mc hangs by several operations.
> >>>
> >>> To reproduce this:
> >>> 1. Start mc with 'env SHELL=tcsh mc -a'
> >>
> >> I mean 'env SHELL=/bin/tcsh mc -a'
> >>
> >>> 2. Select a file using up/down cursor keys.
> >>> 3. Press F3 (View) key.
> > 
> > Thanks for the report.  I can reproduce the problem and will look into it.
> 
> I'm not convinced that this is a FIFO bug.  I tried two things.
> 
> 1. I attached gdb to mc while it was hanging and got the following backtrace 
> (abbreviated):
> 
> #1  0x7ff901638037 in WaitForMultipleObjectsEx ()
> #2  0x7ff901637f1e in WaitForMultipleObjects ()
> #3  0x000180048df5 in cygwait () at ...winsup/cygwin/cygwait.cc:75
> #4  0x00018019b1c0 in wait4 () at ...winsup/cygwin/wait.cc:80
> #5  0x00018019afea in waitpid () at ...winsup/cygwin/wait.cc:28
> #6  0x00018017d2d8 in pclose () at ...winsup/cygwin/syscalls.cc:4627
> #7  0x00018015943b in _sigfe () at sigfe.s:35
> #8  0x00010040d002 in get_popen_information () at filemanager/ext.c:561
> [...]
> 
> So pclose is blocking after calling waitpid.  As far as I can tell from 
> looking 
> at backtraces of all threads, there are no FIFOs open.
> 
> 2. I ran mc under strace (after exporting SHELL=/bin/tcsh), and I didn't see 
> anything suspicious involving FIFOs.  But I saw many EBADF errors from fstat 
> and 
> close that don't appear to be related to FIFOs.
> 
> So my best guess at this point is that the FIFO changes just exposed some 
> unrelated bug(s).
> 
> Prior to the FIFO changes, mc would get an error when it tried to open 
> tcsh_fifo 
> the second time, and it would then set
> 
>mc_global.tty.use_subshell = FALSE;
> 
> see the mc source file subshell/common.c:1087.

I looked into this problem and found pclose() stucks if FIFO
is opened.

Attached is a simple test case. It works under cygwin 3.1.4,
but stucks at pclose() under cygwin git head.

Isn't this a FIFO related issue?

-- 
Takashi Yano 
#include 
#include 
#include 
#include 

int main()
{
	int fifo;
	FILE *p;
	int r;

	printf("Call mkfifo().\n");
	r = mkfifo("fifo1", 0600);
	if (r == 0) printf("mkfifo() success.\n");
	printf("Call open().\n");
	fifo = open("fifo1", O_RDWR);
	if (fifo != -1) printf("open() success.\n");
	printf("Call popen().\n");
	p = popen("/bin/true", "r");
	if (p) printf("popen() success.\n");
	printf("Call pclose().\n");
	r = pclose(p);
	if (r != -1) printf("pclose() success.\n");
	printf("Call close().\n");
	r = close(fifo);
	if (r == 0) printf("close() success.\n");
	printf("Call unlink().\n");
	r = unlink("fifo1");
	if (r == 0) printf("unlink() success.\n");
	return 0;
}

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread jeff


On 5/18/2020 1:01 PM, David Macek via Cygwin wrote:

On Mon, May 18, 2020 at 8:07 PM Adam Dinwoodie  wrote:

Cygwin's `ls` expects the
shell (e.g. Bash) to expand globs like `*`, but Windows' command
prompt expects applications to handle expanding globs (or the Windows
equivalents thereof) themselves. When you call a Cygwin command like
`ls` directly from the Windows command prompt, Windows passes the
arguments as-is to the Cygwin command, and the Cygwin command assumes
that the arguments it received are already appropriately expanded.

This is actually false.  The official FAQ mentions it as well
here.

I went on to investigate what's the issue, but I can't replicate it.
Things like the console code page, the system code
page
could be at play, but I don't see why it would behave like this.

I can make a small tar file with some files with odd names if that would 
help.


jeff

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

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread David Macek via Cygwin

On Mon, May 18, 2020 at 8:07 PM Adam Dinwoodie  wrote:
> Cygwin's `ls` expects the
> shell (e.g. Bash) to expand globs like `*`, but Windows' command
> prompt expects applications to handle expanding globs (or the Windows
> equivalents thereof) themselves. When you call a Cygwin command like
> `ls` directly from the Windows command prompt, Windows passes the
> arguments as-is to the Cygwin command, and the Cygwin command assumes
> that the arguments it received are already appropriately expanded.

This is actually false.  The official FAQ mentions it as well
here.

I went on to investigate what's the issue, but I can't replicate it.
Things like the console code page, the system code
page
could be at play, but I don't see why it would behave like this.

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

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread jeff


On 5/18/2020 11:03 AM, Adam Dinwoodie wrote:

On Mon, 18 May 2020 at 17:21, jeff wrote:

On 5/18/2020 8:55 AM, Andrey Repin wrote:

Greetings, jeff!


I have a directory that has some files with odd files.
I can do a 'ls', successfully. However if I do a 'ls *'' I get:
ls: cannot access '*': No such file or directory
Here is ls output:
'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'
'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'
I am pretty sure this used to work.
This is not specific to ls. wc has the same behavior for example.

Are you trying to run it from Cygwin shell or from some native one, like cmd?


I am running from windows 'command prompt' aka cmd. When run from bash
everything seems to work correctly.

In which case this is expected behaviour: Cygwin's `ls` expects the
shell (e.g. Bash) to expand globs like `*`, but Windows' command
prompt expects applications to handle expanding globs (or the Windows
equivalents thereof) themselves. When you call a Cygwin command like
`ls` directly from the Windows command prompt, Windows passes the
arguments as-is to the Cygwin command, and the Cygwin command assumes
that the arguments it received are already appropriately expanded.

If this was working previously, I can only assume it's because you
were calling Windows' `ls` (which I seem to recall exists and is
essentially an alias for `dir`), which expects Windows semantics and
therefore handles its own expansions.
If the directory doesn't contain any files with odd characters in the 
name, then
'ls *' run from cmd works just fine. Only when there are odd characters 
in the file name is there an issue.


thanks,
jeff


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

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread Adam Dinwoodie

On Mon, 18 May 2020 at 17:21, jeff wrote:
>
> On 5/18/2020 8:55 AM, Andrey Repin wrote:
> > Greetings, jeff!
> >
> >> I have a directory that has some files with odd files.
> >> I can do a 'ls', successfully. However if I do a 'ls *'' I get:
> >> ls: cannot access '*': No such file or directory
> >> Here is ls output:
> >> 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'
> >> 'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'
> >> I am pretty sure this used to work.
> >> This is not specific to ls. wc has the same behavior for example.
> > Are you trying to run it from Cygwin shell or from some native one, like 
> > cmd?
> >
> I am running from windows 'command prompt' aka cmd. When run from bash
> everything seems to work correctly.

In which case this is expected behaviour: Cygwin's `ls` expects the
shell (e.g. Bash) to expand globs like `*`, but Windows' command
prompt expects applications to handle expanding globs (or the Windows
equivalents thereof) themselves. When you call a Cygwin command like
`ls` directly from the Windows command prompt, Windows passes the
arguments as-is to the Cygwin command, and the Cygwin command assumes
that the arguments it received are already appropriately expanded.

If this was working previously, I can only assume it's because you
were calling Windows' `ls` (which I seem to recall exists and is
essentially an alias for `dir`), which expects Windows semantics and
therefore handles its own expansions.

HTH

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

Re: [PATCH 00/21] FIFO: Support multiple readers

2020-05-18 Thread Ken Brown via Cygwin-patches


Hi Takashi,

On 5/18/2020 12:03 PM, Ken Brown via Cygwin-patches wrote:

On 5/18/2020 1:36 AM, Takashi Yano via Cygwin-patches wrote:

On Mon, 18 May 2020 14:25:19 +0900
Takashi Yano via Cygwin-patches  wrote:

However, mc hangs by several operations.

To reproduce this:
1. Start mc with 'env SHELL=tcsh mc -a'


I mean 'env SHELL=/bin/tcsh mc -a'


2. Select a file using up/down cursor keys.
3. Press F3 (View) key.


Thanks for the report.  I can reproduce the problem and will look into it.


I'm not convinced that this is a FIFO bug.  I tried two things.

1. I attached gdb to mc while it was hanging and got the following backtrace 
(abbreviated):


#1  0x7ff901638037 in WaitForMultipleObjectsEx ()
#2  0x7ff901637f1e in WaitForMultipleObjects ()
#3  0x000180048df5 in cygwait () at ...winsup/cygwin/cygwait.cc:75
#4  0x00018019b1c0 in wait4 () at ...winsup/cygwin/wait.cc:80
#5  0x00018019afea in waitpid () at ...winsup/cygwin/wait.cc:28
#6  0x00018017d2d8 in pclose () at ...winsup/cygwin/syscalls.cc:4627
#7  0x00018015943b in _sigfe () at sigfe.s:35
#8  0x00010040d002 in get_popen_information () at filemanager/ext.c:561
[...]

So pclose is blocking after calling waitpid.  As far as I can tell from looking 
at backtraces of all threads, there are no FIFOs open.


2. I ran mc under strace (after exporting SHELL=/bin/tcsh), and I didn't see 
anything suspicious involving FIFOs.  But I saw many EBADF errors from fstat and 
close that don't appear to be related to FIFOs.


So my best guess at this point is that the FIFO changes just exposed some 
unrelated bug(s).


Prior to the FIFO changes, mc would get an error when it tried to open tcsh_fifo 
the second time, and it would then set


  mc_global.tty.use_subshell = FALSE;

see the mc source file subshell/common.c:1087.

Ken

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread jeff


On 5/18/2020 8:55 AM, Andrey Repin wrote:

Greetings, jeff!


I have a directory that has some files with odd files.
I can do a 'ls', successfully. However if I do a 'ls *'' I get:
ls: cannot access '*': No such file or directory
Here is ls output:
'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv'
'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'
I am pretty sure this used to work.
This is not specific to ls. wc has the same behavior for example.

Are you trying to run it from Cygwin shell or from some native one, like cmd?

I am running from windows 'command prompt' aka cmd. When run from bash 
everything seems to work correctly.


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

Re: wildcards don't work in directory with files with odd characters

2020-05-18 Thread Andrey Repin

Greetings, jeff!

> I have a directory that has some files with odd files.
> I can do a 'ls', successfully. However if I do a 'ls *'' I get:
> ls: cannot access '*': No such file or directory

> Here is ls output:
> 'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv' 
> 'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'

> I am pretty sure this used to work.
> This is not specific to ls. wc has the same behavior for example.

Are you trying to run it from Cygwin shell or from some native one, like cmd?

> cygcheck.out is enclosed.


-- 
With best regards,
Andrey Repin
Monday, May 18, 2020 18:55:16

Sorry for my terrible english...

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

Re: [PATCH 00/21] FIFO: Support multiple readers

2020-05-18 Thread Ken Brown via Cygwin-patches


On 5/18/2020 1:36 AM, Takashi Yano via Cygwin-patches wrote:

On Mon, 18 May 2020 14:25:19 +0900
Takashi Yano via Cygwin-patches  wrote:

However, mc hangs by several operations.

To reproduce this:
1. Start mc with 'env SHELL=tcsh mc -a'


I mean 'env SHELL=/bin/tcsh mc -a'


2. Select a file using up/down cursor keys.
3. Press F3 (View) key.


Thanks for the report.  I can reproduce the problem and will look into it.

Ken

Re: issue with reply to mailing list

2020-05-18 Thread Ken Brown via Cygwin


On 5/18/2020 11:07 AM, Jon Turney wrote:

On 16/05/2020 20:42, Marco Atzeri via Cygwin wrote:

On 16.05.2020 20:47, Andrey Repin wrote:

Greetings, Marco Atzeri!


it is just me or the cygwin mailing lists post are not
reporting anymore the reply to the list tag ?


You seems to have replied to an off-list mail.

msgid:0d9b4a1b-05ba-8ab1-3783-c3d1f04f9...@gmail.com is not found in my list
archive.


not that the issue.
That give me the idea that I am not the only one with the issue,
as I am changing manually the send to address and sometime
I forget or screw ups.


I am using Thunderbird and the option reply to list is not
offered anymore for any of the cygwin mailing list.


Ask Thunderbid, what it expects as an indication of a "list message" ?
There's a bunch of "List-" headers.


looking in chronological order, I see the problem on the cygwin-apps
and developer mailing lists from the date of server change.

The cygwin main list seems to not have the same issue.
But it can be an issue with Thunderbird as I have impression
to had the same issue also with it.


Comparing the configuration of the lists, the only significant difference I 
noticed is that cygwin-apps is not configured to add a 'List-Post' header.


Searching there does seem to be suggestions that the presence of this header 
causes Thunderbird to display a 'Reply to List' button.


I changed the cygwin-apps list configuration to add that.  Let me know if that 
makes things better (or worse!).


I was seeing the same issue as Marco, and it appears to be fixed now.  (The 
latest message from Brian to cygwin-apps shows the Reply List button.)  I'm also 
seeing the issue on cygwin-patches and cygwin-developers.  Can you fix those too?


Thanks.

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

Re: cygport ... install starts in cwd but ... all does not

2020-05-18 Thread Brian Inglis

On 2020-05-17 02:13, Marco Atzeri via Cygwin-apps wrote:
> On 17.05.2020 08:45, Brian Inglis wrote:
>> When rerunning a cygport build with "cygport *.cygport all" after fixing up
>> problems stage by stage, "doicon $NAME.png" at the start of src_install, 
>> before
>> "cd/pushd ${B}" fails with fatal message "*** ERROR: file $NAME.png does not
>> exist", whereas rerunning "cygport *.cygport install" succeeds without any
>> messages.
>>
>> Even changing cd to pushd, and adding popd at the end of each src_... 
>> function,
>> does not solve the issue.
>>
>> The package does not include an icon, so I downloaded something suitable to 
>> the
>> same package directory as the $NAME.cygport and *.patch PATCH_URI files.
>>
>> Any alternative approaches that anyone can suggest might work?
>>
> 
> can we see the file ?
> May be is a banal issue that you are oversighting

Doh - of course - attached!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

#|/usr/bin/cygport
# tek4010.cygport - tek4010 Cygwin package build control script

NAME=tek4010
VERSION=1.5
RELEASE=1

CATEGORY="X11 Shells"
SUMMARY="Tektronix 4010, 4013, 4014, 4015 and ARDS terminal emulator"
DESCRIPTION="
Full support of Tektronix 4010, 4013, 4014, and 4015 storage tube
terminals, and Computer Displays Inc. Advanced Remote Display Station
for Project MAC.
Coordinate system: 4096x3072 Tek points and 1024x780: full screen
resolution in -full mode; standard resolution of 1024x780 points;
scaled smaller resolution for lower resolution screens.
All Tektronix 4014 modes, including graphical input mode (GIN),
write-through mode, grayscale images (Tektronix 4014 intensity chart),
and the bright drawing spot support.
APL character set and keyboard for Tektronix 4013 and Tektronix 4015.
Direct display of GNU and historical plotlib files.
Telnet, rsh, and serial connections to historical host computers and
simulators."

HOMEPAGE="https://github.com/rricharz/Tek4010;
GIT_URI="https://github.com/rricharz/Tek4010.git;
PATCH_URI="makefile.patch tube.c.patch"

inherit git

# no src subdirectory
SRC_DIR=Tek4010

# use DESTDIR
USE_DESTDIR=1

# Build dependencies
DEPEND="make binutils gcc-core libgtk3-devel"

src_compile() {
pushd ${B}
lndirs
/bin/rm -f $NAME
cygmake
popd
}

# test must be on terminal: just list version
src_test()
{
pushd ${B}
./$NAME
/bin/true
popd
}

inherit font

src_install() {
doicon Tek4010.png
pushd ${B}
cyginstall
# version log, manuals dir README png
dodoc versions.txt *.png manuals/*.*
# APL font and tests
insinto /usr/share/$NAME/apl
doins apl/*
fontinto Apl385
dofont apl/Apl385.ttf
# ARDS emulator files
insinto /usr/share/$NAME/ardsfiles
doins ardsfiles/*.*
# plotlib files
insinto /usr/share/$NAME/pltfiles
doins pltfiles/*.* *.plt
insinto /usr/share/$NAME/pltfiles/gsxbasic
doins pltfiles/gsxbasic/*.*
insinto /usr/share/$NAME/pltfiles/ICEMD_pltfiles
doins pltfiles/ICEMD_pltfiles/*.*
insinto /usr/share/$NAME/pltfiles/More_pltfiles
doins pltfiles/More_pltfiles/*.*
insinto /usr/share/$NAME/pltfiles/PointPlot
doins pltfiles/PointPlot/*.*
# test programs
insinto /usr/share/$NAME/tektests
doins tektests/*
# demo scripts
exeinto /usr/share/$NAME/demos
doexe demo.sh fdemo.sh gdemo.sh demo.sh ICEMD_demo.sh
# X desktop
make_desktop_entry "/usr/bin/tek4010 -noexit" Tek4010 Tek4010 \

'Graphics;Viewer;2DGraphics;VectorGraphics;System;TerminalEmulator;GTK' \
"Tektronix 4010, 4013, 4014, 4015 Storage Tube and ARDS Graphical Display 
Terminal Emulator" \
GenericName=Terminal Terminal=no
popd
}

# SPDX-License-Identifier: MIT-like
LICENSE="GPL3"
LICENSE_SPDX="SPDX-License-Identifier: GPL3"
LICENSE_URI="LICENCE"

CYGWIN_MAINTAINER="Brian%20Inglis"
CYGWIN_MAINTAINER_EMAIL="brian.ing...@systematicsw.ab.ca"
UPSTREAM_MAINTAINER="Rene Richarz"
UPSTREAM_MAINTAINER_EMAIL="rrichar...@gmail.com"
SUBJECT="Package%20$NAME%20$VERSION"
MAILTO="mailto:$UPSTREAM_MAINTAINER_EMAIL,$UPSTREAM_EMAIL\
?to=$UPSTREAM_MAINTAINER%20%3C$UPSTREAM_MAINTAINER_EMAIL%3E\
=$UPSTREAM_MAINTAINER%20%3C$UPSTREAM_EMAIL%3E\
=$CYGWIN_MAINTAINER%20%3C$CYGWIN_MAINTAINER_EMAIL%3E\
=$SUBJECT=$SUBJECT"

# vim:ft=sh:

Re: issue with reply to mailing list

2020-05-18 Thread Jon Turney


On 16/05/2020 20:42, Marco Atzeri via Cygwin wrote:

On 16.05.2020 20:47, Andrey Repin wrote:

Greetings, Marco Atzeri!


it is just me or the cygwin mailing lists post are not
reporting anymore the reply to the list tag ?


You seems to have replied to an off-list mail.

msgid:0d9b4a1b-05ba-8ab1-3783-c3d1f04f9...@gmail.com is not found in 
my list

archive.


not that the issue.
That give me the idea that I am not the only one with the issue,
as I am changing manually the send to address and sometime
I forget or screw ups.


I am using Thunderbird and the option reply to list is not
offered anymore for any of the cygwin mailing list.


Ask Thunderbid, what it expects as an indication of a "list message" ?
There's a bunch of "List-" headers.


looking in chronological order, I see the problem on the cygwin-apps
and developer mailing lists from the date of server change.

The cygwin main list seems to not have the same issue.
But it can be an issue with Thunderbird as I have impression
to had the same issue also with it.


Comparing the configuration of the lists, the only significant 
difference I noticed is that cygwin-apps is not configured to add a 
'List-Post' header.


Searching there does seem to be suggestions that the presence of this 
header causes Thunderbird to display a 'Reply to List' button.


I changed the cygwin-apps list configuration to add that.  Let me know 
if that makes things better (or worse!).


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

[ANNOUNCEMENT] meson 0.54.2-1

2020-05-18 Thread Jon Turney




The following packages have been uploaded to the Cygwin distribution:

* meson-0.54.2-1

Meson is an open source build system meant to be extremely fast.  It 
generates files for various backends including Ninja, Visual Studio, and 
Xcode. Meson does not generate Makefiles, relying solely on Ninja for 
Linux and Unix support.


This is an update to the latest upstream release:

https://mesonbuild.com/Release-notes-for-0-54-0.html

noarch:
ab2fd2f16f390456efb6f57ffa75680c65fd09518cc08d855bb06d4fa444f64bf6d15632a85e64b9e8b6c7cb815d269968e214f4e047f99408350723522e959d 
*meson-0.54.2-1-src.tar.xz
5e86f6ef3c7df63df210dc1ec96a46ce4c6bc572c7ea17d1f2dc172cd308e3fc578fd151cb52c738e95e4989101b62ba147025451b31c3cd43b11e68c1d5a404 
*meson-0.54.2-1.tar.xz

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

meson 0.54.2-1

2020-05-18 Thread Jon Turney




The following packages have been uploaded to the Cygwin distribution:

* meson-0.54.2-1

Meson is an open source build system meant to be extremely fast.  It 
generates files for various backends including Ninja, Visual Studio, and 
Xcode. Meson does not generate Makefiles, relying solely on Ninja for 
Linux and Unix support.


This is an update to the latest upstream release:

https://mesonbuild.com/Release-notes-for-0-54-0.html

noarch:
ab2fd2f16f390456efb6f57ffa75680c65fd09518cc08d855bb06d4fa444f64bf6d15632a85e64b9e8b6c7cb815d269968e214f4e047f99408350723522e959d 
*meson-0.54.2-1-src.tar.xz
5e86f6ef3c7df63df210dc1ec96a46ce4c6bc572c7ea17d1f2dc172cd308e3fc578fd151cb52c738e95e4989101b62ba147025451b31c3cd43b11e68c1d5a404 
*meson-0.54.2-1.tar.xz

wildcards don't work in directory with files with odd characters

2020-05-18 Thread jeff


I have a directory that has some files with odd files.
I can do a 'ls', successfully. However if I do a 'ls *'' I get:
ls: cannot access '*': No such file or directory

Here is ls output:
'Highlander-S03E21-Final'$'\303\251''_Part_I-22.mkv' 
'Highlander-S03E22-Final'$'\303\251''_Part_II-23.mkv'


I am pretty sure this used to work.
This is not specific to ls. wc has the same behavior for example.

cygcheck.out is enclosed.

thanks,
jeff


Cygwin Configuration Diagnostics
Current System Time: Mon May 18 05:34:35 2020

Windows 10 Professional Ver 10.0 Build 18363 

Path:   C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\Program Files\Supermicro\SuperDoctor5
C:\Program Files\Calibre2\
C:\Users\jdeifik\AppData\Local\Microsoft\WindowsApps
c:\cygwin64\bin
c:\cygwin64\usr\local\bin
u:\j\bin
.

Output from c:\cygwin64\bin\id.exe
UID: 197609(jdeifik)   GID: 197121(None)
197121(None)   545(Users)
4(INTERACTIVE) 66049(CONSOLE LOGON)
11(Authenticated Users)15(This Organization)
113(Local account) 4095(CurrentSession)
66048(LOCAL)   262154(NTLM Authentication)
401408(Medium Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

Path = 
'C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program
 Files\Supermicro\SuperDoctor5;C:\Program 
Files\Calibre2\;C:\Users\jdeifik\AppData\Local\Microsoft\WindowsApps;c:\cygwin64\bin;c:\cygwin64\usr\local\bin;u:\j\bin;'

ALLUSERSPROFILE = 'C:\ProgramData'
APPDATA = 'C:\Users\jdeifik\AppData\Roaming'
CommonProgramFiles = 'C:\Program Files\Common Files'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
CommonProgramW6432 = 'C:\Program Files\Common Files'
COMPUTERNAME = 'EPYC_16'
ComSpec = 'C:\Windows\system32\cmd.exe'
DriverData = 'C:\Windows\System32\Drivers\DriverData'
FPS_BROWSER_APP_PROFILE_STRING = 'Internet Explorer'
FPS_BROWSER_USER_PROFILE_STRING = 'Default'
GPU_MAX_ALLOC_PERCENT = '100'
GPU_MAX_HEAP_SIZE = '100'
GPU_SINGLE_ALLOC_PERCENT = '100'
HOMEDRIVE = 'C:'
HOMEPATH = '\Users\jdeifik'
Isuser = 
'C:\Users\jdeifik\AppData\Local\Temp\{BD0758D3-489F-41A9-AF17-57C231EF5C3B}\{0F86FD09-BA63-4E45-A70B-604C1106C2F2}\_isuser_0x0409.dll'
LOCALAPPDATA = 'C:\Users\jdeifik\AppData\Local'
LOGONSERVER = '\\EPYC_16'
MOZ_PLUGIN_PATH = 'C:\Program Files (x86)\Foxit Software\Foxit Reader\plugins\'
NUMBER_OF_PROCESSORS = '32'
OneDrive = 'C:\Users\jdeifik\OneDrive'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
PROCESSOR_ARCHITECTURE = 'AMD64'
PROCESSOR_IDENTIFIER = 'AMD64 Family 23 Model 49 Stepping 0, AuthenticAMD'
PROCESSOR_LEVEL = '23'
PROCESSOR_REVISION = '3100'
ProgramData = 'C:\ProgramData'
ProgramFiles = 'C:\Program Files'
ProgramFiles(x86) = 'C:\Program Files (x86)'
ProgramW6432 = 'C:\Program Files'
PROMPT = '$P$G'
PSModulePath = 'C:\Program 
Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program
 Files\Intel\Wired Networking\'
PUBLIC = 'C:\Users\Public'
SAN_DIR = 'C:\Program Files\SiSoftware\SiSoftware Sandra Lite 2020'
SD5_HOME = 'C:\Program Files\Supermicro\SuperDoctor5\'
SESSIONNAME = 'Console'
SystemDrive = 'C:'
SystemRoot = 'C:\Windows'
TEMP = 'C:\Users\jdeifik\AppData\Local\Temp'
TMP = 'C:\Users\jdeifik\AppData\Local\Temp'
USERDOMAIN = 'EPYC_16'
USERDOMAIN_ROAMINGPROFILE = 'EPYC_16'
USERNAME = 'jdeifik'
USERPROFILE = 'C:\Users\jdeifik'
VBOX_MSI_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
windir = 'C:\Windows'

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\c:\cygwin64'
  e652b24f317f4c0d = '\??\K:\password-cracking\john-1.9.0-jumbo-1-win64'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:\cygwin64'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin64'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: e022582115c10879 Path: C:\cygwin64
  User:   Key: e022582115c10879 Path: c:\cygwin64
  User:   Key: e652b24f317f4c0d Path: 
K:\password-cracking\john-1.9.0-jumbo-1-win64 (ORPHANED)

c:  hd  NTFS149354Mb  45% CP CS UN PA FCQU  
d:  cd N/AN/A   
j:  hd  NTFS   3682275Mb  33% CP CS UN PA FCQU  WD_8a_mp3_av
k:  hd  NTFS   3682275Mb  54% CP CS UN PA FCQU  WD_8a_Backup
m:  hd  NTFS   3813878Mb  36% CP CS UN PA FCQU  WD_8b_tv_current
n:  hd  NTFS   3817002Mb  39% CP CS UN PA FCQU  WD_8b_cancelled_tv
u:  hd  NTFS266329Mb  24% CP CS UN PA FCQU  WD_8a_User

c:\cygwin64  /  system  binary,auto
c:\cygwin64\bin  /usr/bin   system  binary,auto
c:\cygwin64\lib  /usr/lib   system  binary,auto
cygdrive prefix  /cygdrive  user

Re: Cannot use Cygwin64 with MSVC 64-bit DLL

2020-05-18 Thread Marco Atzeri via Cygwin


On 17.05.2020 23:03, Old Wolf via Cygwin wrote:

Hi all

I am ultimately trying to use Cygwin 64-bit to port a Solaris server 
application which uses the Informix Client SDK.  However, the Win64 version of 
that product comes as a binary-only distribution of DLLs built by MSVC .

I have managed to reproduce the problem in a simple test case.  I made a full 
writeup here: https://stackoverflow.com/questions/61812131/

In brief, linking a 64-bit DLL created by MSVC with early binding to any program built 
with /usr/bin/gcc  (or /usr/bin/g++) produces a runtime error "The procedure entry 
point __cxa_atexit could not be located in the dynamic link library 
F:\temp\mre.exe" .  (Also, if the executable is launched from the Cygwin shell no 
output appears; I see this error popup by launching from command prompt).

However the testcase does work correctly if I use late binding (i.e. 
LoadLibrary and GetProcAddress).  But this is a considerable nuisance in 
comparison to early binding (i.e. linking against the DLL's import library).  
It also works correctly under MSYS2 , and native-target mingw-w64.  Only 
Cygwin64 early-binding exhibits the problem.

I don't have the option of trying to rebuild the import library as suggested in comments 
to my SO question, as the Informix DLL is stripped .  I would like to use Cygwin as 
opposed to MSYS2 because the application uses SYSV IPC which is supported by Cygwin. So I 
need to either resolve this problem, create my own "import library" with late 
binding thunks for every function, or rewrite the SYSV IPC stuff to WinAPI stuff and use 
MSYS2 instead. Hoping the first of those three options turns out to be possible!

Regards,
M.M.
--



the __cxa_atexit is available from the cygwin1.dll itself.
Have you tried to add "-lcygwin" at the end of your command line:

g++ -o mre.exe mre.cc /f/temp/simpledll/x64/Debug/simpledll.lib -lcygwin

As it should be the default linking, I doubt it is that the root cause.

May be the difference is in the 64 bit models

https://cygwin.com/cygwin-ug-net/programming.html#gcc-64

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

[PATCH 2/3] Cygwin: tzcode resync v2: imports

[PATCH 0/3] Cygwin: tzcode resync v2

[PATCH 3/3] Cygwin: tzcode resync v2: details

[PATCH 1/3] Cygwin: tzcode resync v2: basics

Re: wildcards don't work in directory with files with odd characters

Re: [PATCH 00/21] FIFO: Support multiple readers

Re: wildcards don't work in directory with files with odd characters

Re: wildcards don't work in directory with files with odd characters

Re: wildcards don't work in directory with files with odd characters

Re: wildcards don't work in directory with files with odd characters

Re: [PATCH 00/21] FIFO: Support multiple readers

Re: wildcards don't work in directory with files with odd characters

Re: wildcards don't work in directory with files with odd characters

Re: [PATCH 00/21] FIFO: Support multiple readers

Re: issue with reply to mailing list

Re: cygport ... install starts in cwd but ... all does not

Re: issue with reply to mailing list

[ANNOUNCEMENT] meson 0.54.2-1

meson 0.54.2-1

wildcards don't work in directory with files with odd characters

Re: Cannot use Cygwin64 with MSVC 64-bit DLL

21 matches

Site Navigation

Mail list logo

Footer information