Re: Emacs portability requirements

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, collin.fu...@gmail.com, bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 17:39:46 +0200 > > Thanks, Eli. Everything is clear now (from my side). Glad I could help. > We will be able to avoid that Gnulib destabilizes Emacs, better than > we could in the

Re: Emacs portability requirements

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, collin.fu...@gmail.com, bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 16:58:44 +0200 > > > Windows 9X in general don't have any _w* "wide" functions, and need to > > use UNICOWS.DLL to do so. > > You're confusing me now. I see many _w* "wide"

Re: Emacs portability requirements

> From: Bruno Haible > Cc: Paul Eggert , Collin Funk , > bug-gnulib@gnu.org > Date: Thu, 06 Jun 2024 09:47:30 +0200 > > 1) > > On Windows 9X > > Emacs loads the UNICOWS.DLL shared library at startup to be able to > > use some functions ... > > Can the source code call the functions of

Re: platforms without

> Date: Wed, 5 Jun 2024 11:45:07 -0700 > Cc: bug-gnulib@gnu.org > From: Paul Eggert > > On 2024-06-05 09:22, Bruno Haible wrote: > > > why not choose the Gnulib approach, namely to let the 'locale' > > module provide the replacement if this header file is missing? > > Because that would drag

Re: Gnulib's boot-time.c breaks the build with mingw.org's MinGW

> From: Collin Funk > Cc: Paul Eggert , Bruno Haible , > emacs-de...@gnu.org, bug-gnulib@gnu.org > Date: Tue, 04 Jun 2024 11:39:12 -0700 > > Eli Zaretskii writes: > > > However, that header is not really needed here because the > > signature of the GetTick

Gnulib's boot-time.c breaks the build with mingw.org's MinGW

Paul imported today the latest changes from Gnulib, and that broke the Emacs MinGW build on the master branch when mingw.org's MinGW is used: boot-time.c:49:11: fatal error: sysinfoapi.h: No such file or directory 49 | # include | ^~ compilation terminated.

Re: c32width gives incorrect return values in C locale

> From: Bruno Haible > Cc: bug-libunistr...@gnu.org > Date: Sat, 11 Nov 2023 23:54:52 +0100 > > [CCing bug-libunistring] > Gavin Smith wrote: > > I did not understand why uc_width was said to be "locale dependent": > > > > "These functions are locale dependent." > > > > - from > >

Re: errors from fchownat copying directories

> From: Bruno Haible > Cc: emacs-de...@gnu.org, bug-gnulib@gnu.org > Date: Sat, 26 Aug 2023 18:40:20 +0200 > > Paul Eggert wrote: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=349798a9b81fb4f7f8e1e1963ea9039a4a68a471 > > Isn't there something missing in this function

Re: gettimeofday.c windows version?

> Date: Fri, 23 Dec 2022 23:42:52 -0800 > Cc: rogerdp...@gmail.com, br...@clisp.org, bug-gnulib@gnu.org > From: Paul Eggert > > On 12/23/22 22:46, Eli Zaretskii wrote: > > We do this only for mingw.org's MinGW, not for MinGW64 (where we don't > > change the default

Re: gettimeofday.c windows version?

> Date: Fri, 23 Dec 2022 15:47:27 -0800 > Cc: bug-gnulib@gnu.org, Eli Zaretskii > From: Paul Eggert > > nt/inc/ms-w32.h has a "#define _WIN32_WINNT 0x0400" that should be > overriding the MingW default. We do this only for mingw.org's MinGW, not for MinGW64 (where

Re: gettimeofday.c windows version?

> From: Roger Pack > Date: Fri, 23 Dec 2022 01:38:01 -0700 > Cc: bug-gnulib@gnu.org, Eli Zaretskii > > OK it appears newer mingw have a default target of windows 10 for some > reason. gnutls embedded in this > case: > $ x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.

Re: gettimeofday.c windows version?

> Date: Fri, 16 Dec 2022 15:35:27 -0800 > Cc: br...@clisp.org, bug-gnulib@gnu.org, rogerdp...@gmail.com > From: Paul Eggert > > On 12/12/22 12:37, Eli Zaretskii wrote: > > It should be easy to arrange for Emacs to compile Gnulib source code > with whatever value of _WI

Re: gettimeofday.c windows version?

> Date: Mon, 12 Dec 2022 11:44:43 -0800 > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > From: Paul Eggert > > On 12/12/22 06:40, Eli Zaretskii wrote: > > A program's build could use certain cpp switches for some of its > > sources, and other switches for the ot

Re: gettimeofday.c windows version?

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > Date: Mon, 12 Dec 2022 15:25:58 +0100 > > Eli Zaretskii wrote: > > And Gnulib > > is a library, so it is IMO wrong for it to decide for the applications > > on what OS they can and cannot run.

Re: gettimeofday.c windows version?

> Date: Sun, 11 Dec 2022 23:17:32 -0800 > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > From: Paul Eggert > > That being said, I'm not quite understanding the underlying issue here. I'll try to explain. > Is it that MinGW has "#define _WIN32_WINNT 0x502", which as I understand > from [1]

Re: gettimeofday.c windows version?

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > Date: Sun, 11 Dec 2022 19:25:12 +0100 > > Doing a web search, I now see from > > that 10% of Windows users are still using Window 7. Whereas

Re: gettimeofday.c windows version?

> Date: Sun, 11 Dec 2022 18:56:00 +0200 > From: Eli Zaretskii > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > > > As some point, I want to get rid of the initialize() function and assume > > a new enough version of the OS. > > When that happens, Emacs will not be

Re: gettimeofday.c windows version?

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, rogerdp...@gmail.com > Date: Sun, 11 Dec 2022 17:20:07 +0100 > > > I think the code should use a run-time check regardless of the version > > of Windows on which the program was compiled. > > But the value of _WIN32_WINNT is not the version *on*

Re: gettimeofday.c windows version?

> From: Bruno Haible > Cc: Roger Pack , Eli Zaretskii > Date: Sun, 11 Dec 2022 15:22:23 +0100 > > Eli: What are the current support statements of Emacs regarding Windows > XP/Vista/7 ? Emacs still supports even Windows 9X. And mingw.org's MinGW does the same. Which is why

Re: namespacing issues with Gnulib

> From: Bruno Haible > Cc: gavinsmith0...@gmail.com, s...@gentoo.org, bug-texi...@gnu.org, > bug-gnulib@gnu.org > Date: Thu, 08 Dec 2022 20:00:31 +0100 > > Eli Zaretskii wrote: > > > Attempting to --whole-archive link on that platform grants us: > > > >

Re: -Wlto-type-mismatch warning in error()

> From: Arsen Arsenović > Cc: Bruno Haible , gavinsmith0...@gmail.com, > s...@gentoo.org, bug-texi...@gnu.org, bug-gnulib@gnu.org > Date: Thu, 08 Dec 2022 09:25:01 +0100 > > > Shouldn't we report this to the GCC folks? It could be a bug in lto, > > no? I mean, 'error' is not a symbol that

Re: -Wlto-type-mismatch warning in error()

> From: Bruno Haible > Date: Thu, 08 Dec 2022 01:21:51 +0100 > > Gavin Smith wrote: > > I expect it is not a gnulib problem. install-info/install-info.c declares > > a function called "error" which appears to clash with a function from glibc. > > ... The "error" module is brought in by "xalloc"

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 23 Aug 2022 16:49:36 +0200 > > Eli Zaretskii asked: > > > Yes. Running the "case 2" part 1000 times again, amon

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: Eli Zaretskii , bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 23 Aug 2022 02:13:02 +0200 > > > If I understand things > > correctly, these patches should fix the 0.1% failure rate you ob

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org, > jporterb...@gmail.com > Date: Sun, 21 Aug 2022 18:20:52 +0200 > > I changed test-tempname.c to skip the case 1 and execute only case 2, and > added printf statements per the attached tempname.c.diff. Then

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Wed, 17 Aug 2022 23:05:33 -0700 > Cc: br...@clisp.org, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > From: Paul Eggert > > On 8/17/22 04:08, Eli Zaretskii wrote: > > Would it be possible to cherry-pick this to the emacs-28 b

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 16 Aug 2022 22:06:13 +0200 > > Eli Zaretskii wrote: > > Emacs has a with-temp-file macro, which generates a temporary file >

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Tue, 16 Aug 2022 12:11:24 -0700 > Cc: br...@clisp.org, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > From: Paul Eggert > > > Thanks, but why not use 'random' instead? Emacs does have it on all > > platforms, including MS-Windows. AFAIU, it's

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 16 Aug 2022 19:29:33 +0200 > > > The buffer which visited that file still exists, and still records the > > name of the file, yes. And then, when the

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Tue, 16 Aug 2022 10:30:54 -0700 > Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org, > jporterb...@gmail.com, br...@clisp.org > From: Paul Eggert > > On 8/16/22 10:04, Eli Zaretskii wrote: > > That "finite number" of 62^6 sounds pretty close

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Tue, 16 Aug 2022 10:25:57 -0700 > Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org, > jporterb...@gmail.com > From: Paul Eggert > > On 8/16/22 09:25, Eli Zaretskii wrote: > > why does this work differently on > > different platforms? > &g

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Cc: jporterb...@gmail.com, la...@gnus.org, bug-gnulib@gnu.org, > 57...@debbugs.gnu.org, br...@clisp.org > Date: Tue, 16 Aug 2022 20:04:49 +0300 > From: Eli Zaretskii > > Therefore, if there's no intention to fix this in Gnulib, I'm going to > update the documentation

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Tue, 16 Aug 2022 09:54:25 -0700 > Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org, > jporterb...@gmail.com, Bruno Haible > From: Paul Eggert > > On 8/16/22 09:25, Eli Zaretskii wrote: > > The programmer didn't > > expect that because it

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org, > 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 16 Aug 2022 16:40:16 +0200 > > Eli Zaretskii wrote: > > Looking at your test program, I see that you generate the seconds file &

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> From: Bruno Haible > Cc: la...@gnus.org, 57...@debbugs.gnu.org, jporterb...@gmail.com > Date: Tue, 16 Aug 2022 15:35:17 +0200 > > Eli Zaretskii wrote: > > The problem is that callers of > > make-temp-file reasonably expect it to return a new name every call.

Re: bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

> Date: Mon, 15 Aug 2022 13:55:35 -0700 > Cc: la...@gnus.org, 57...@debbugs.gnu.org, Jim Porter > , Gnulib bugs > From: Paul Eggert > > On 8/15/22 11:58, Eli Zaretskii wrote: > > > Ah, okay. It's a (mis)feature of Gnulib's gen_tempname function > > (wh

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Thu, 21 Apr 2022 16:56:25 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > What appears to be happening here is that the MS-Windows native > timestamp resolution is 1/64th of a second, and your system's clock is

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Fri, 22 Apr 2022 00:23:01 +0700 > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, 54...@debbugs.gnu.org > From: Max Nikulin > > >> Clock resolution generally has a little common with timers. > > > > I agree, but that's something you should tell/ask Paul, not myself. > > It may be deeper,

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Thu, 21 Apr 2022 22:30:21 +0700 > Cc: bug-gnulib@gnu.org, 54...@debbugs.gnu.org > From: Max Nikulin > > Eli Zaretskii, Wed, 20 Apr 2022 22:30:21 > > I see the time samples change in jumps of 15 msec. Which is expected > > on MS-Windows, given the scheduler

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Wed, 20 Apr 2022 17:11:34 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > On 4/20/22 12:30, Eli Zaretskii wrote: > > > I see the time samples change in jumps of 15 msec. > &

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Wed, 20 Apr 2022 12:23:43 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > On 4/20/22 12:14, Eli Zaretskii wrote: > > Sorry, my bad. The result is the same, but I do get printouts. What

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Wed, 20 Apr 2022 12:01:27 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > bug-gnulib@gnu.org > From: Paul Eggert > > > I get the same result, and moreover I see no differences between this > > and the previous tarball, and no printouts in

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

> Date: Wed, 20 Apr 2022 11:19:29 -0700 > Cc: maniku...@gmail.com, emacs-orgm...@gnu.org, 54...@debbugs.gnu.org, > Gnulib bugs > From: Paul Eggert > > > Thanks, the test-gettime-res test says "gettime_res returned 625000 > > ns", which is a strange number: it doesn't fit any MS-Windows

Re: Emacs 28.1 doesn't compile on Mac OS 10.7.5

> Feedback-ID: matti...@acm.or > From: Mattias Engdegård > Date: Sun, 17 Apr 2022 11:13:43 +0200 > Cc: dpo...@macports.org, Gnulib bugs , > Filipp Gunbin , Emacs-Devel > > 17 apr. 2022 kl. 04.21 skrev Paul Eggert : > > > > On 4/15/22 09:22, Mattias Engdegård wrote: > >> Paul, would you

Re: bug#32452: 26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy

> From: Lars Ingebrigtsen > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, npost...@gmail.com, > 32...@debbugs.gnu.org > Date: Mon, 28 Feb 2022 13:35:47 +0100 > > Lars Ingebrigtsen writes: > > > grep --color=auto -nH --null -e rpl_nanosleep `find . -type f` > > ./lib/time.h647:#define

Re: bug#32452: 26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy

> From: Lars Ingebrigtsen > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, npost...@gmail.com, > 32...@debbugs.gnu.org > Date: Mon, 28 Feb 2022 09:59:39 +0100 > > /usr/bin/ld: gnutls.o: in function `gnutls_try_handshake': > /home/larsi/src/emacs/trunk/src/gnutls.c:634: undefined reference to >

Re: bug#32452: 26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy

> From: Lars Ingebrigtsen > Cc: Noam Postavsky , 32...@debbugs.gnu.org, Eli > Zaretskii , Gnulib bugs > Date: Sat, 26 Feb 2022 16:12:23 +0100 > > Paul Eggert writes: > > > Gnulib's nanosleep appears to use select only for old Unixish > > platforms that

Re: Emacs build fails on Windows mingw64

> From: Bruno Haible > Date: Mon, 25 Oct 2021 00:52:45 +0200 > Cc: Andy Moreton , emacs-de...@gnu.org > > This patch should fix it. > > > 2021-10-24 Bruno Haible > > string: Avoid syntax error re strdup in string.in.h (regr. 2021-09-07). > Reported by Jan Engelhardt >

Re: Emacs build fails on Windows mingw64

> From: Óscar Fuentes > Date: Sun, 24 Oct 2021 20:01:06 +0200 > Cc: bug-gnulib@gnu.org > > Paul Eggert writes: > > > I don't know why the > > problem occurs only for GCC 11 on MS-Windows platforms, as I would > > think it'd also occur with earlier GCC versions. > > Most likely the problem is

Re: Emacs build fails on Windows mingw64

> Cc: andrewjmore...@gmail.com, bug-gnulib@gnu.org, emacs-de...@gnu.org > From: Paul Eggert > Date: Sun, 24 Oct 2021 13:05:32 -0400 > > On 10/24/21 9:58 AM, Eli Zaretskii wrote: > > We could try all that, but not on the release branch. There, I'd like > > a simple and

Re: Emacs build fails on Windows mingw64

> Cc: andrewjmore...@gmail.com, bug-gnulib@gnu.org, emacs-de...@gnu.org > From: Paul Eggert > Date: Sun, 24 Oct 2021 08:25:29 -0400 > > > ntlib cannot include config.h, > > due to various redefinitions and redirections we do in ms-w32.h for > > Emacs. > > I now see Emacs has a symbol

Re: Emacs build fails on Windows mingw64

> From: Paul Eggert > Date: Sat, 23 Oct 2021 23:45:04 -0400 > Cc: bug-gnulib@gnu.org, emacs-de...@gnu.org > > On 10/23/21 4:42 PM, Andy Moreton wrote: > > Can this issue be addressed in gnulib so the emacs bug can be fixed ? > > This appears to be an issue in Emacs not Gnulib, as a few of

Re: bug#33847: 27.0.50; emacsclient does not find server socket

> Cc: la...@gnus.org, te...@gmx.com, 33...@debbugs.gnu.org, u...@gentoo.org, > Gnulib bugs > From: Paul Eggert > Date: Sun, 25 Jul 2021 09:22:06 -0700 > > On 7/24/21 11:32 PM, Eli Zaretskii wrote: > > >> No modules are affected by the --disable-year2038 option on

Missing type cast in select.c

Compiling Gnulib's select.c with mingw.org's MinGW produces the following warnings: In file included from select.c:24: select.c: In function 'rpl_select': select.c:534:25: warning: passing argument 1 of 'rpl_fd_isset' makes integer from pointer without a cast [-Wint-conversion]

Re: Seeking input from developers: glibc copyright assignment policy.

> From: Paul Smith > Date: Tue, 15 Jun 2021 12:32:35 -0400 > > On Tue, 2021-06-15 at 07:03 -0500, Eric Blake wrote: > > I recall how long it took for me to get permission to sign assignment > > papers from my previous employer, for work I was doing in my spare > > time, and being able to use the

Re: Support GLOB_TILDE_CHECK for ~user in glob.c on MS-Windows

> From: Bruno Haible > Cc: Eli Zaretskii > Date: Tue, 30 Mar 2021 02:50:53 +0200 > > > +#else /* WINDOWS32 */ > > + /* We don't support ~USER on MS-Windows (FIXME: could have > > +at least supported that if USER == $USERNAME). */ > >

Support GLOB_TILDE_CHECK for ~user in glob.c on MS-Windows

When Gnulib's glob.c is used on MS-Windows, tilde expansion in the likes of "~foo" always "succeeds", even when GLOB_TILDE_CHECK is set in the flags, although in this case 'glob' simply punts and returns the original unexpanded argument. Suggested minimal patch is below: --- glob.c~

swab wrapper fails mingw.org's MinGW compilation of GDB

The following snippet from Gnulib's unistd.h causes a compilation error when building the current development version of GDB 11: #if @GNULIB_MDA_SWAB@ /* On native Windows, map 'swab' to '_swab', so that -loldnames is not required. In C++ with GNULIB_NAMESPACE, avoid differences between

Re: How to avoid fdopen redefinition?

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, gavinsmith0...@gmail.com > Date: Mon, 01 Mar 2021 21:38:34 +0100 > > Eli Zaretskii wrote: > > > If you request the gnulib module 'setlocale', you will get not only > > > LC_MESSAGES, but also

Re: How to avoid fdopen redefinition?

> From: Bruno Haible > Cc: Gavin Smith , Eli Zaretskii > Date: Mon, 01 Mar 2021 17:46:02 +0100 > > "MS-Windows doesn't support LC_MESSAGES in its >setlocale API, I guess that's what triggers the problem." > > If you request the gnulib module

Re: Signals on Mingw

> From: Reuben Thomas > Date: Mon, 23 Nov 2020 16:38:22 + > Cc: Bruno Haible , bug-gnulib > > Can you elaborate what are you using this module for in the MinGW > build? AFAIK, Posix signals can never work well enough on Windows to > care about them. Maybe I'm missing something. > >

Re: Signals on Mingw

> From: Reuben Thomas > Date: Sun, 22 Nov 2020 23:46:37 + > Cc: bug-gnulib > >- Is it useful to have these signal names defined at all? If they can never > occur on native Windows, it does not necessarily make sense to define > them. > > If I wanted native (non-POSIX)

Re: Compilation problems with stat-w32.c

> From: Bruno Haible > Cc: Eli Zaretskii > Date: Wed, 16 Sep 2020 23:54:28 +0200 > > You are right on both accounts. Thanks for the reports. Should be fixed > by the two attached patches. Thanks! > > In addition, VOLUME_NAME_NONE is used here, but the Windows headers

Compilation problems with stat-w32.c

I've built today's snapshot of GDB on MS-Windows, and bumped into a problem: starting the produced binary on Windows XP fails with this message: The procedure entry point GetFinalPathNameByHandleA could not be located in the dynamic link library KERNEL32.dll. This happens because

Re: Gnulib's alloca.h and MinGW

> From: Bruno Haible > Cc: Eli Zaretskii > Date: Tue, 30 Jun 2020 00:55:49 +0200 > > > Proposed patch is below. Thanks. > > Thanks for the report. > > I like your patch. It is better than the '#undef alloca' solution that I > had considered before. Thanks.

Re: socklen_t data type

> From: Bruno Haible > Cc: Eli Zaretskii , Keith Marshall > , Rahul Das > Date: Tue, 30 Jun 2020 03:07:39 +0200 > > >makes available a type, socklen_t, which is an > > unsigned opaque integral type of length of at least 32 bits. > > The page you c

Gnulib's alloca.h and MinGW

A recent MinGW runtime changed its definition of alloca from an inline function to a macro. As result, there's a warning when compiling Gnulib's malloca.c: CC malloca.o In file included from malloca.h:21, from malloca.c:22: ./alloca.h:46: warning:

socklen_t data type

Gnulib's sys/socket.h has this: # if @HAVE_WINSOCK2_H@ /* Include headers needed by the emulation code. */ # include # include # if !GNULIB_defined_socklen_t typedef int socklen_t; # define GNULIB_defined_socklen_t 1 # endif # endif This unconditionally defines

Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64

> Cc: 42...@debbugs.gnu.org, "Peder O. Klingenberg" , > Gnulib bugs > From: Paul Eggert > Date: Sun, 28 Jun 2020 13:34:36 -0700 > > As I understand it the basic issue here is that we want O_CLOEXEC support even > on platforms that lack it, and we don't want all the calling software to play >

Re: Problems compiling 'getrandom' with MinGW

> From: Bruno Haible > Cc: Eli Zaretskii > Date: Sun, 28 Jun 2020 19:19:10 +0200 > > > 1. It assumes that the header bcrypt.h is always available. This is > > true for MinGW64, but not for mingw.org's MinGW. A proposed patch to > > allow the code be comp

Problems compiling 'getrandom' with MinGW

The current version of Gnulib's 'getrandom' has a couple of problems when compiled with MinGW: 1. It assumes that the header bcrypt.h is always available. This is true for MinGW64, but not for mingw.org's MinGW. A proposed patch to allow the code be compiled without bcrypt.h is below, it is

Re: Problematic redefinition of 'stat' and 'fstat'

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Wed, 25 Dec 2019 12:13:54 -0800 > > On 12/24/19 7:34 PM, Eli Zaretskii wrote: > > I will have to hack Gnulib > > by hand in each project I'll need to compile. > > './configure --disable-largefile' shou

Re: Problematic redefinition of 'stat' and 'fstat'

> From: Bruno Haible > Cc: Eli Zaretskii > Date: Tue, 24 Dec 2019 22:42:06 +0100 > > > Which is exactly what happened to me > > while building the latest versions of GDB, which uses Gnulib, but > > links against the BFD library, which doesn't. > > The BFD

Re: Problematic redefinition of 'stat' and 'fstat'

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Tue, 24 Dec 2019 10:51:54 -0800 > > On 12/24/19 10:29 AM, Eli Zaretskii wrote: > > > I'm not talking about file offsets, > > I'm talking about st_size only. > > Why distinguish between the two? Because on

Re: Problematic redefinition of 'stat' and 'fstat'

> From: Paul Eggert > Cc: bug-gnulib@gnu.org > Date: Tue, 24 Dec 2019 10:08:51 -0800 > > On 12/24/19 9:25 AM, Eli Zaretskii wrote: > > if the default definition > > of 'struct stat' uses 32-bit st_size field, then linking a program > > against a library which wa

Problematic redefinition of 'stat' and 'fstat'

The current sys_stat.in.h in Gnulib does this on MinGW: /* Large File Support on native Windows. */ #if @WINDOWS_64_BIT_ST_SIZE@ # define stat _stati64 #endif [...] #elif @WINDOWS_64_BIT_ST_SIZE@ /* Above, we define stat to _stati64. */ # define fstat _fstati64 [...] #

Re: localcharset: optimize code for native Windows.

> From: Bruno Haible > Date: Tue, 17 Dec 2019 15:06:50 +0100 > > The localcharset code for native Windows first fetches > setlocale (LC_ALL, NULL), then notices "oh, this is not what we want", > then fetches setlocale (LC_CTYPE, NULL). > > Example: > > LC_CTYPE => "English_United

Re: new module 'access'

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, psm...@gnu.org > Date: Sat, 28 Sep 2019 15:29:42 +0200 > > > > The module does not attempt to handle all of these, just the first one, > > > because > > > - the function access() is located at the C library level, > > > - it is compatible with

Re: new module 'access'

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, psm...@gnu.org > Date: Sat, 28 Sep 2019 14:06:00 +0200 > > There are different ways to test for "executable" on Windows: > - execlp/execvp, > - CreateProcess, > - system / popen, like you say, > - cmd.exe, > - surely more (PowerShell...) >

Re: new module 'access'

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, psm...@gnu.org > Date: Tue, 17 Sep 2019 00:45:03 +0200 > > > > +@item > > > +This function does not support the @code{X_OK} mode on some platforms: > > > +MSVC 14. > > > > This says MSVC, but the code will do the same on MinGW, right? > > Yes, I

Re: [PATCH] findprog-in: Set errno to indicate why NULL was returned.

> From: Bruno Haible > Cc: Paul Smith > Date: Sun, 15 Sep 2019 19:58:56 +0200 > > + - Otherwise, it sets errno and returns NULL. > + Specific errno values include: > + - ENOENT: means that the program's file was not found. > + - EACCESS: means that the program's file was found

Re: new module 'access'

> From: Bruno Haible > Cc: Paul Smith > Date: Sun, 15 Sep 2019 19:11:25 +0200 > > +@item > +This function does not support the @code{X_OK} mode on some platforms: > +MSVC 14. This says MSVC, but the code will do the same on MinGW, right? > +int > +access (const char *file, int mode) > +{ > +

Re: INT_ADD_WRAPV and friends - bug fixed

> From: Paul Eggert > Cc: bug-gnulib@gnu.org > Date: Wed, 14 Aug 2019 17:48:04 -0700 > > Eli Zaretskii wrote: > >https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37006 > > Thanks for reporting that bug. I fixed it by installing the attached into > Gnulib. Than

INT_ADD_WRAPV and friends considered harmful

Please take a look at the problem described in this bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37006 The upshot is that an innocent use of INT_ADD_WRAPV, even by experienced programmers, can quite unexpectedly produce spectacular failures. Frankly, I was astonished to discover

Re: Variant wcwidth results on Solaris

> From: Gavin Smith > Date: Sat, 30 Mar 2019 09:27:26 + > Cc: bug-gnulib@gnu.org, bug-texi...@gnu.org > > > Another approach is to not include the code from gnulib, but instead > > rely on a preinstalled GNU libunistring. For this, use the gnulib > > module 'libunistring'. > > libunistring

Re: Gnulib's alloca.h used even when there is a system header

> From: Bruno Haible > Cc: ke...@users.osdn.me, bug-gnulib@gnu.org, egg...@cs.ucla.edu > Date: Sun, 10 Mar 2019 20:54:20 +0100 > > Pushed. Thank you. And thanks to Keith for his thorough research.

Re: Gnulib's alloca.h used even when there is a system header

> From: Bruno Haible > Cc: Eli Zaretskii , bug-gnulib@gnu.org, egg...@cs.ucla.edu > Date: Sun, 10 Mar 2019 20:03:33 +0100 > > So, Gnulib's alloca.h and the system's alloca.h are both included, and > the system's alloca.h comes last. To avoid this kind of trouble, we

Re: Gnulib's alloca.h used even when there is a system header

Ping! This discussion seems to have stalled, without reaching any firms conclusion. Can we please finish discussing this? Or maybe it is OK to install the patch I proposed up-thread? TIA > Date: Tue, 19 Feb 2019 19:18:15 +0200 > From: Eli Zaretskii > CC: bug-gnulib@gnu

Re: Gnulib's alloca.h used even when there is a system header

> From: Bruno Haible > Cc: Eli Zaretskii , Paul Eggert > Date: Tue, 19 Feb 2019 00:32:24 +0100 > > Hi Eli, > > > ./alloca.h:40:18: error: inlining failed in call to always_inline > > '__builtin_alloca': function not considered for inlining > >

Re: Gnulib's alloca.h used even when there is a system header

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Sun, 17 Feb 2019 13:09:06 -0800 > > Eli Zaretskii wrote: > > #ifndef alloca > > # ifdef __GNUC__ > > -# define alloca __builtin_alloca > > +# if HAVE_ALLOCA_H > > +# include_next > &g

Re: Gnulib's alloca.h used even when there is a system header

> Cc: bug-gnulib@gnu.org > From: Paul Eggert > Date: Sun, 17 Feb 2019 12:06:53 -0800 > > This stuff is rickety, as it's built atop Autoconf's AC_FUNC_ALLOCA and that > stuff hasn't changed in at least a decade. In the old days, some alloca > implementations were broken and when in doubt it was

Gnulib's alloca.h used even when there is a system header

Building the latest version of Texinfo, I see that Gnulib decides to generate its own alloca.h header even though there's a system header alloca.h (and HAVE_ALLOCA_H is 1 in config.h). Why does it do that? Isn't that dangerous? e.g., it could conflict with how the system header defies 'alloca',

Re: localename: Fix gettext test failures on mingw

> From: Bruno Haible > Cc: bug-gnulib@gnu.org > Date: Sun, 25 Nov 2018 19:27:44 +0100 > > > It defines symbols based on LC_MESSAGES and exposes them > > to Scheme. > > What was the problem with that? Since guile is based on the > platform's runtime + gnulib, not the platform's runtime alone, >

Re: localename: Fix gettext test failures on mingw

> From: Bruno Haible > Cc: bug-gnulib@gnu.org > Date: Sun, 25 Nov 2018 19:27:44 +0100 > > > I think it's important to share my experience here, ... > > The problems I describe are not theoretical, I actually bumped into > > them when porting Guile 2.0.x. > > Ah, I wasn't aware that you were

Re: localename: Fix gettext test failures on mingw

> From: Bruno Haible > Cc: bug-gnulib@gnu.org > Date: Sat, 24 Nov 2018 21:32:58 +0100 > > > We could have gettext work without LC_MESSAGES, by using native > > Windows calls instead, couldn't we? > > That was the way it was done before Gnulib. Remember how, up to ca. 2001, > porting a program

Re: localename: Fix gettext test failures on mingw

> From: Bruno Haible > Cc: bug-gnulib@gnu.org > Date: Sat, 24 Nov 2018 12:20:21 +0100 > > > LC_MESSAGES means nothing on MS-Windows, so why does Gnulib need to > > "fix" something that is not supported by the runtime library? > > On native Windows, LC_MESSAGES is indeed not defined by the

Re: localename: Fix gettext test failures on mingw

> From: Bruno Haible > Date: Sat, 24 Nov 2018 02:16:24 +0100 > > Several of the GNU gettext tests fail on mingw. The reason is that > these tests > - use the LOCALE_FR=French_France.1252 value found during autoconfiguration, > - set the LC_ALL environment variable to this value. > The GNU

Re: hierarchical projects with configure scripts

> From: Tom Tromey > Cc: Tom Tromey , Bruno Haible , Paul > Eggert , bug-gnulib@gnu.org, gdb-patc...@sourceware.org > Date: Sat, 01 Sep 2018 00:05:26 -0600 > > Sergio> I don't know if just requiring C99 or later would be enough to solve > Sergio> this problem, but it's something to consider

Re: New warnings on emacs-26 branch with gcc 8.2.0

> From: Bruno Haible > Cc: bug-gnulib@gnu.org, egg...@cs.ucla.edu, andrewjmore...@gmail.com, > emacs-de...@gnu.org > Date: Sun, 19 Aug 2018 02:17:52 +0200 > > > diff --git a/lib/gettimeofday.c b/lib/gettimeofday.c > > index bff40d7..36b5074 100644 > > --- a/lib/gettimeofday.c > > +++

Re: New warnings on emacs-26 branch with gcc 8.2.0

> Cc: br...@clisp.org, bug-gnulib@gnu.org, andrewjmore...@gmail.com, > emacs-de...@gnu.org > From: Paul Eggert > Date: Sat, 18 Aug 2018 11:59:03 -0700 > > Eli Zaretskii wrote: > > There's no need to disable this warning at all. > > I thought the problem was that p

  1   2   3   4   >