Re: symbolic link curiousity in 3.6.0

2025-03-29 Thread Brian Inglis
On 2025-03-29 12:14, Brian Inglis via Cygwin wrote: On 2025-03-29 08:02, Bruno Haible via Cygwin wrote: Corinna Vinschen wrote: Regarding what acl_extended_file() does, there is the man page by Andreas Grünbacher: https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html

Re: symbolic link curiousity in 3.6.0

2025-03-28 Thread Brian Inglis
d a while longer, while I work around the latest releases changes! ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not

Re: localtime on native Windows

2024-02-17 Thread Brian . Inglis
On 2024-02-17 19:14, Bruno Haible wrote: Brian Inglis wrote: I was looking around ... that required data can be shrunk to ~300KB using Brotli!? Whereas the entire tzdata.zi (without comments, and with abbreviations) is only around 100 KB. I'll definitely prefer the latter. Other op

Re: localtime on native Windows

2024-02-13 Thread Brian Inglis
al built-in POSIX TZ parser and the POSIX TZ rules output by: tail -1 /usr/share/zoneinfo/**/* for the selected time zones, including time zone ids and rules: 12.6KB, 4KB zip, 3.8KB gz, 3.5KB xz/lz/bz2. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La per

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-23 Thread Brian Inglis
On 2021-09-20 21:25, Akim Demaille wrote: Le 18 sept. 2021 à 19:04, Brian Inglis a écrit : Thanks very much for your help Bruno, in diagnosing the issue correctly, and providing the patch: I will ensure your patch comment gets prefixed into the respun bison gnulib patch. And thanks Akim for

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-18 Thread Brian Inglis
On 2021-09-18 09:10, Bruno Haible wrote: Brian Inglis wrote: Respun and applied patch successfully to glm4/threadlib.m4. Did you regenerate the 'configure' script, and also do 'make distclean', after patching threadlib.m4? Find attached a new 'testdir-thread' p

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-18 Thread Brian Inglis
On 2021-09-18 10:15, Brian Inglis wrote: On 2021-09-18 09:10, Bruno Haible wrote: Brian Inglis wrote: Respun and applied patch successfully to glm4/threadlib.m4. Did you regenerate the 'configure' script, and also do 'make distclean', after patching threadlib.m4?

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-18 Thread Brian Inglis
On 2021-09-18 09:10, Bruno Haible wrote: Brian Inglis wrote: Respun and applied patch successfully to glm4/threadlib.m4. Did you regenerate the 'configure' script, and also do 'make distclean', after patching threadlib.m4? Find attached a new 'testdir-thread' p

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-18 Thread Brian Inglis
On 2021-09-18 07:22, Brian Inglis wrote: On 2021-09-17 14:25, Bruno Haible wrote: Brian Inglis wrote: Can you also try to build it through     gl_cv_have_weak=no ../configure -C && make && make check in a different subdirectory? Please send the config.log, config.cache, co

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-18 Thread Brian Inglis
On 2021-09-17 14:25, Bruno Haible wrote: Brian Inglis wrote: Can you also try to build it through gl_cv_have_weak=no ../configure -C && make && make check in a different subdirectory? Please send the config.log, config.cache, config.status, and gltests/test-suite.log for

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-17 Thread Brian Inglis
On 2021-09-16 12:08, Bruno Haible wrote: Brian Inglis wrote: Please note that latest bison built and passed all checks on latest Cygwin 32. The issue is only with Cygwin 64. I consistently reproduced the SEGV @ 0x0001 with trashed stack, in a gdb script. Comparing the test

Re: bison segv under Cygwin 64 at fatal-signal.c:318

2021-09-16 Thread Brian Inglis
seful check logs. I will also redo cygport with --disable-silent-rules after those builds and checks complete (in a few hours). -- 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