Re: Issue with intprops-internal.h / GCC 8.3

On Sat, 2024-03-30 at 02:17 +0100, Bruno Haible wrote: >     The problem with your git repository setup (maintMakefile line 32, >     that enables -Werror by default) is that in practice, it's not >     only developers who build from git repositories. Namely, many people >     whose habits have

Issue with intprops-internal.h / GCC 8.3

I have a bug report for a compiler error in GNU Make, using intprops-internal.h, on Debian 10 with GCC 8.3: https://savannah.gnu.org/bugs/?65537 This is with gnulib stable-202401 current Git HEAD. Thoughts? Maybe I just have to disable this warning? Note, I already do not enable -Werror etc.

Re: Does gnulib getcwd always allocate if buf is NULL?

On Wed, 2024-03-06 at 19:55 +0100, Reuben Thomas wrote: > In getcwd.c I find the following comment: > > > In GNU, if BUF is NULL, an array is allocated with 'malloc'; the > > array is SIZE bytes long, unless SIZE == 0, in which case it is as > > big as necessary. > > However, as far as I can see

Re: removing permissions for long unused accounts, take 2

On Thu, 2023-03-09 at 15:54 +0100, Bruno Haible wrote: > If you have a checkout of GNU gnulib, in order to successfully do a > "git pull" again, you will have to change the .git/config file, Is it better to suggest Git's CLI interface for this, than edit the file? For example git remote

Re: Instructions on new bootstrap?

On Sat, 2022-07-30 at 22:55 +0200, Bruno Haible wrote: > Paul Smith wrote: > > > In your case, the sync already happened. So, either you must have > > > had > > >    bootstrap_sync=true > > > in your bootstrap.conf, or you passed the option --bootstra

Re: Instructions on new bootstrap?

On Sat, 2022-07-30 at 22:01 +0200, Bruno Haible wrote: > > which seems to imply that unless I add that flag or set > > bootstrap_sync in my bootstrap.conf file (which I did not), the > > sync won't happen. > > In your case, the sync already happened. So, either you must have had >  

Instructions on new bootstrap?

Are there instructions on how the new model of bootstrap is supposed to be used somewhere? I can't quite figure it out. I pulled in the latest gnulib/build-aux/bootstrap and ran it, then when it was complete git shows: Changes not staged for commit: modified: bootstrap Untracked

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

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 DCO instead would have made my > efforts easier at that time. This is

Re: cmp/diff

On Sat, 2020-12-26 at 19:49 +0100, Bruno Haible wrote: > Makefile rules are written both for automated execution and for the > developers of a package. While for the automated execution of a unit > test, "cmp expected.out actual.out" is sufficient, for a developer, > "diff expected.out actual.out"

Re: [Manual] Unreadable navigation links and oversize titles

On Sun, 2020-12-13 at 17:58 +0100, Thérèse Godefroy wrote: > 2. Huge headings. > It's not only a matter of taste. They decrease usability on > smartphones. I have to agree with Thérèse on this: the new font sizes are too big. It feels like the author is shouting at me when I read them. I also

Re: Relicense findprog-in under LGPLv2+

On Sun, 2020-12-06 at 22:59 +0100, Bruno Haible wrote: > I would like to relicense the module 'findprog-in' under LGPLv2+, so > that I can use it for the native Windows implementation of the > modules 'posix_spawn' and 'posix_spawnp' — which are under LGPLv2+. > > This module has one contribution

Re: improve clang support (34)

On Sun, 2020-08-16 at 22:54 +0200, Bruno Haible wrote: > This Makefile variable HAVE_INCLUDE_NEXT is not used in Gnulib, but > some packages may be using it. I included this module in the clang > support for completeness. Thanks; I wasn't really asking about this particular change per se, rather

Re: improve clang support (34)

On Sun, 2020-08-16 at 18:55 +0200, Bruno Haible wrote: > +HAVE_INCLUDE_NEXT = (__GNUC__ || __clang__ || 6000 <= __DECC_VER) Just wondering, are these changes for the sake of documentation, or are they really needed (do you see problems without them)? In my experience with clang, it always

Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

On Sun, 2020-08-02 at 18:58 -0400, Paul Smith wrote: > If I compare the configure output from a run with using the cache > (fails) with one that doesn't use the cache (succeeds) the only > difference of interest is: > > @@ -378,7 +379,7 @@ >checking whether progr

Re: bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

On Sun, 2020-08-02 at 17:54 -0400, Paul Smith wrote: > The latest Bison release 3.7.1 is not compiling for me, and it > appears to be a gnulib issue. > > Here's the failure: > > gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \ > -DDEFAULT_TEXT

bison 3.7.1 failing to build on Centos 7: verify_NSIG_constraint

The latest Bison release 3.7.1 is not compiling for me, and it appears to be a gnulib issue. Here's the failure: gcc -DEXEEXT=\"\" -I. -I./lib -Ibison-3.7.1 -Ibison-3.7.1/lib \ -DDEFAULT_TEXT_DOMAIN=\"bison-gnulib\" -march=nehalem -mtune=intel \ -ffile-prefix-map=bison-3.7.1/= -O2 -fPIC

Re: Versioned releases

On Thu, 2020-06-04 at 23:29 +0200, Bruno Haible wrote: > I disagree on this one. It would make people think that the Nth > commit, or the Monday commit, or whatever, is preferred over the > other commits. Which it really isn't - there may be a regression fix > coming in just the next day. I'm

Re: Versioned releases

On Thu, 2020-06-04 at 23:11 +0300, Dmitry Marakasov wrote: > * Paul Smith (psm...@gnu.org) wrote: > > > Regarding the format of the version: > > > > First, semver is not right for gnulib. The entire concept behind > > semver and similar versioning sche

Re: Versioned releases

On Thu, 2020-06-04 at 20:19 +0200, Bruno Haible wrote: > Are you suggesting that every gnulib commit can be translated to a > version number? There's 'git describe' which does that. > > Or are you suggesting that the Gnulib developers pick, say, every > 100th Gnulib commit and assign it a version

Re: find_in_given_path(): not handling directories properly

On Fri, 2020-05-22 at 01:05 -0400, Paul Smith wrote: > However, the same issue exists in lib/findprog-in.c, in the > find_in_given_path() (which is what GNU make actually uses), and that > function wasn't updated by the above commit. Thanks for addressing this, Bruno!

Update to docs etc.

It's been pointed out on the GNU make lists that by including gnulib content we've effectively updated our minimum required compiler from C90 to C99. That may be acceptable, but I think the gnulib docs (at least), if not gnulib-tool, should make clear that AC_PROG_CC_C99 (at least) needs to be

find_in_given_path(): not handling directories properly

In gnulib commit 7b1de4a62f876: commit 7b1de4a62f8766787160f785217671b074e0f0f2 Author: Bruno Haible Date: 2020-04-10 15:57:10 +0200 findprog, relocatable-prog: Ignore directories during PATH search. Reported by Frederick Eaton via Dmitry Goncharov in

Re: reclaiming memory before exit, take 2

On Sat, 2020-05-16 at 16:04 +0200, Bruno Haible wrote: > Paul writes in [1]: > > In any event, it seems to me to be a deficiency in the detection if > > it reports allocated memory which is still referenced to by global > > variables, or even static variables, as memory leaks. > > On the

Re: reclaiming memory before exit

On Sat, 2020-05-16 at 01:03 +0200, Bruno Haible wrote: > Well, my experience is different. Last month, I analyzed a program > that uses GNU libtextstyle, and the valgrind "leak" reports could be > categorized into three groups: > * 1056 + 296 + 56 bytes, allocated through

Re: reclaiming memory before exit

On Fri, 2020-05-15 at 21:58 +0200, Bruno Haible wrote: > Another possibility is to standardize on a GCC attribute for > functions, with the meaning "memory allocations done inside this > functions are on the same level as static initializations and don't > need to be reclaimed before program

Re: reclaiming memory before exit

On Fri, 2020-05-15 at 16:38 -0400, Jeffrey Walton wrote: > On Fri, May 15, 2020 at 4:23 PM Paul Eggert > wrote: > > On 5/15/20 10:52 AM, Kamil Dudka wrote: > > > I do not understand why you take it personally. > > > > I didn't take it personally. The email in question wasn't even > > directed at

Re: [PATCH 0/1] old-fashioned suffix rules cannot have any prerequisites

Sorry, somehow the original email went by me. On Thu, 2020-04-02 at 02:01 +0200, Bruno Haible wrote: > Petr Ovtchenkov wrote in > > > > Template po/Makefile.in.in use old-fashioned suffix rules > > for generating .gmo. But

Using git: in the bootstrap script?

One of my users has reported that the gnulib-supplied bootstrap script is failing for them, but if they change: default_gnulib_url=git://git.sv.gnu.org/gnulib to: default_gnulib_url=https://git.savannah.gnu.org/git/gnulib it works. My suspicion is that they're behind a firewall which

Re: Why does gnulib use makefile rules rather than configure?

On Sun, 2019-09-08 at 16:40 -0700, Paul Eggert wrote: > Admittedly GNU Make is a special case, since you want to build it > without having 'make'. And if it's just a few Gnulib modules and > they're not doing anything fancy, perhaps we can modify the modules > to use 'configure' substitutions

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

On Sat, 2019-09-14 at 15:35 -0400, Paul Smith wrote: > Set errno to either ENOENT if the program was not found, or another > error if a program was found but was no suitable (i.e., EACCES). Without this change it's impossible for a program to show the correct error message when the p

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

Set errno to either ENOENT if the program was not found, or another error if a program was found but was no suitable (i.e., EACCES). * modules/findprog: Depend on errno. * lib/findprog-in.c (find_in_given_path): Save errno if it is not ENOENT and reset errno before returning NULL. *

Why does gnulib use makefile rules rather than configure?

I'm looking at allowing GNU make to use more gnulib facilities, but I've run into a serious problem. It seems that a lot of gnulib modules rely on makefile rules added to Makefile.in to construct files, rather than using traditional configure replacement .in file conversions. This is a real

Re: [PATCH] findprog: Support searching in a specified path string

On Sun, 2019-09-08 at 19:48 +0200, Bruno Haible wrote: > > My suggestion was that BOTH these functions should not assume the CWD > > if PATH is empty or missing, not that they should behave differently. > > OK. But what, do you suggest, should the functions do when confronted to > an empty path?

Re: [PATCH] findprog: Support searching in a specified path string

On Sun, 2019-09-08 at 16:59 +0200, Bruno Haible wrote: > Hi Paul, > > > > > prog = find_in_path_str ("myprog", lookup_path ()); > > > > > > > > and if lookup_path() returns NULL it defaults to the environment > > > > PATH, > > > > > > I don't think NULL should be interpreted as "look in the

Re: [PATCH] findprog: Support searching in a specified path string

On Sun, 2019-09-08 at 13:38 +0200, Bruno Haible wrote: > > the path search is done > > on the _parent's_ PATH environment value not the one passed in to > > posix_spawnp(). I don't want that, I need the search done in the > > child's environment. I can't decide if this behavior by > >

Re: [PATCH] findprog: Support searching in a specified path string

On Sat, 2019-09-07 at 12:42 +0200, Bruno Haible wrote: > Hi Paul, > > find_prog_in_path() always uses the PATH value in the current > > environment. It can be very useful to search for programs on > > a path without having to modify the environment first. > > > > Provide find_in_path_str()

Re: [PATCH] findprog: Support searching in a specified path string

I don't know if people would prefer to actually define two real functions one of which just invokes the other, rather than use a preprocessor macro to forward the old one to the new one. I'm fine with it either way. On Fri, 2019-09-06 at 19:10 -0400, Paul Smith wrote: > find_prog_in_p

[PATCH] findprog: Support searching in a specified path string

find_prog_in_path() always uses the PATH value in the current environment. It can be very useful to search for programs on a path without having to modify the environment first. Provide find_in_path_str() which takes a path string to search. If the path passed in is NULL, fall back to searching

Re: relocatable-prog: Use $ORIGIN trick on more platforms

On Wed, 2019-02-20 at 02:45 +0100, Bruno Haible wrote: > Paul Smith noted on gnu-prog-discuss that other systems than glibc > have support for $ORIGIN in rpath. This patch changes the > 'relocatable-prog' module to make use of this feature, thus removing > the need for a "wra

Re: gnulib's translation

On Sun, 2018-12-02 at 15:38 +0100, Benno Schulenberg wrote: > > Ah, you were assuming that the POT file is stored in the version > > control system? This is a practice that produces problems, > > What problems does this produce? (Probably this was discussed > earlier and elsewhere? Maybe have

Why does gnulib generate alloca.h, sys/types.h, unistd.h on GNU/Linux?

I've switched over to using a few gnulib modules in GNU make. I've just noticed that whenever I run configure, even though I'm on a GNU/Linux system with GNU libc 2.27 and a fairly modern GCC 7.3, the configure script insists on generating local copies of standard header files: lib/alloca.h

Re: gnulib getloadavg: incorrect .Po included in root Makefile.in

On Thu, 2018-06-21 at 23:12 +0200, Bruno Haible wrote: > Paul Smith wrote: > > However, for lib/getloadavg.c and ONLY for that lib/*.c file, I > > ALSO get duplicate rules in my root Makefile.in > > Does it cause an actual problem, or does it only "feel" wron

[PATCH] getloadavg: Don't redefine WINDOWS32.

* lib/getloadavg.c: Only define WINDOWS32 if it's not already defined. --- lib/getloadavg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/getloadavg.c b/lib/getloadavg.c index 435d10a..578316e 100644 --- a/lib/getloadavg.c +++ b/lib/getloadavg.c @@ -97,7 +97,7 @@ #

Re: gnulib getloadavg: incorrect .Po included in root Makefile.in

On Mon, 2018-06-18 at 18:33 +0200, Bruno Haible wrote: > Hi Paul, > > > I'm on a GNU/Linux system with autoconf 2.69, automake 1.15.1, ... > > ... > >Makefile:1021: lib/.deps/getloadavg.Po: No such file or directory > > You might try automake 1.16.1 instead. Its handling of files under >

gnulib getloadavg: incorrect .Po included in root Makefile.in

Hi all. I'm on a GNU/Linux system with autoconf 2.69, automake 1.15.1, gettext 0.19.8.1, latest gnulib checked out from Git. I'm seeing an issue when using the getloadavg gnulib module. The problem is that I find a line in my root Makefile.in which attempts to include the

Re: [PATCH] getloadavg: Allow building on Windows without Cygwin

On Sun, 2018-06-17 at 22:31 +0200, Bruno Haible wrote: > > I thought in general we were avoiding use of the _WINxx > > preprocessor defines, and instead preferring WINDOWS32. > > Maybe in general in GNU. But not in gnulib. > > > > But there is no implementation for native Windows! > > > > True,

Re: [PATCH] getloadavg: Allow building on Windows without Cygwin

On Mon, 2018-05-21 at 01:26 +0200, Bruno Haible wrote: > Hi Paul, > The proper condition for testing for a native Windows platform is > #if defined _WIN32 && ! defined __CYGWIN__ Does this mean you'd prefer to see a patch that tested this before including unistd.h, versus the HAVE_UNISTD_H

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On Wed, 2018-05-16 at 19:33 +0300, Eli Zaretskii wrote: > > these values. Or else I have to create per-system instances of > > each of these files, of which I already have 5 just for alloca and > > getloadavg and if I do take on glob/fnmatch that number will > > balloon. > > For the record: what

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On Wed, 2018-05-16 at 11:29 +0200, Bruno Haible wrote: > This approach with "build_w32.bat" is outdated. The modern approach is > to use the Autoconf and Automake generated configure and Makefile.in > files without modifications. > More in detail: About ca. 10 years ago, Automake started to

Re: Gnulib on Windows (native / mingw32) / VMS / etc.

On Fri, 2018-04-13 at 10:42 +0300, Eli Zaretskii wrote: > > This might require changing Gnulib to make it easier to decouple its > > glob.c and fnmatch.c from the rest of Gnulib. We've done that for > > some of the Gnulib modules that Emacs uses, and I expect we could do > > that for glob.c and

[PATCH] bootstrap: Avoid gnulib operations if not needed.

* build-aux/bootstrap: Remove unused variable gnulib_mk. Set $gnulib_extra_files early so it can be overridden in .conf. Remove redundant --import flag from $gnulib_tool_options. Set $use_gnulib to false if no gnulib modules or files are needed. If $use_gnulib is false, don't do anything related

[PATCH] bootstrap: Avoid gnulib operations if not needed

Re: [PATCH] bootstrap: Avoid gnulib operations if not needed

On Sat, 2018-04-28 at 14:00 -0700, Paul Eggert wrote: > Thanks, but it looks like Evolution broke the patch by folding lines; could > you > please resend it as an attachment? "git format-patch" is a good way to format > patches, and I use "git send-email" to send them if you prefer not to use

[PATCH] bootstrap: Avoid gnulib operations if not needed

* build-aux/bootstrap: Remove unused variable gnulib_mk. Set $gnulib_extra_files early so it can be overridden in .conf. Remove redundant --import flag from $gnulib_tool_options. Set $use_gnulib to false if no gnulib modules or files are needed. If $use_gnulib is false, don't do anything related

Gnulib on Windows (native / mingw32) / VMS / etc.

Hi all. I spent a bit of time this weekend looking into what it would take to update GNU make to use the glob/fnmatch implementations from the current gnulib, rather than the ancient (and buggy) implementation that GNU make has embedded, more or less unchanged, for at least 25 years. This,

Question about portability guidelines

Looking at the portability guidelines[1] there is some confusion; early on it says: > Currently we assume at least a freestanding C89 compiler But then later in that same section I see things like: > The GNU coding standards allow one departure from strict C99 and: > Hence Gnulib code should