Re: 'relocatable' project built without --enable-relocatable

On Thu, 25 Apr 2024 at 14:07, Bruno Haible wrote: > OK, I'm committing as shown below. > Great, thanks! > Is there a reason not to make a similar macro for compute_curr_prefix? > > Yes: > - For compute_curr_prefix, the need has not been demonstrated. > - Even if ENABLE_RELOCATABLE is 1,

Re: 'relocatable' project built without --enable-relocatable

On Wed, 24 Apr 2024 at 01:24, Bruno Haible wrote: > > Can you please try the attached patch? > Works beautifully, thanks. (Sorry to cause confusion: I was actually quoting code from a C-based project, not a Vala-based project, where I don't need the fix. But if you install this patch then I

Re: Gnulib in Debian

On Wed, 24 Apr 2024 at 15:56, Simon Josefsson wrote: > > The last aspect should be solved: the latest gnulib in Debian contains a > git bundle of gnulib, That's fantastic, I wish I had thought of that. I still don't fancy doing the necessary packaging work, but I'll let those who have been

Re: Gnulib in Debian

On Wed, 24 Apr 2024 at 01:51, Bruno Haible wrote: > Reuben Thomas wrote: > > (not yet in Debian, sadly, as they don't like me "vendoring gnulib", as > FTP > > Master calls it, or "using gnulib as other packages like Enchant do, and > as > > designed"

Re: 'relocatable' project built without --enable-relocatable

On Tue, 23 Apr 2024 at 21:46, Bruno Haible wrote: > How does or would the code you are talking about look like, with #ifs? > And would it be code for a library, or for a program? > For a library. For example, from the libpaper commit referenced below, using #ifdefs: /* Set the prefix directory

'relocatable' project built without --enable-relocatable

relocatable.h has partial support for building without --enable-relocatable: it #defines relocate and relocate2 to empty macros. This is great! Could macros be similarly added for the other relocatable.h APIs, namely set_relocation_prefix and compute_curr_prefix? This would allow relocate-using

Re: Problem with DATADIR on Mingw

On Fri, 12 Apr 2024 at 21:20, Bruno Haible wrote: > Reuben Thomas wrote: > > gcc -DHAVE_CONFIG_H -I. -I.. --include configmake.h --include config.h > Oh dear, the command-line includes were right in front of me, sorry! > > ... enchant.c > > If you #include these tw

Re: Problem with DATADIR on Mingw

On Fri, 12 Apr 2024 at 18:55, Bruno Haible wrote: > Reuben Thomas wrote: > > With up-to-date gnulib (and I can't see any relevant changes for some > > years), I am getting the following error while using the configmake > module > > and building on Mingw 64 x86_64: >

Problem with DATADIR on Mingw

With up-to-date gnulib (and I can't see any relevant changes for some years), I am getting the following error while using the configmake module and building on Mingw 64 x86_64: In file included from : C:/msys64/mingw64/include/objidl.h:10677:3: error: expected identifier or '(' before string

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

On Wed, 6 Mar 2024 at 21:45, Bruno Haible wrote: > > There's no need to change this comment, because the primary places to look > for a function's behaviour are: > 1. the documentation and standard documents, > 2. the .h file (in this case: unistd.in.h line 1121). > Fair enough that there

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

On Wed, 6 Mar 2024 at 20:12, Bruno Haible wrote: > Reuben Thomas wrote: > > In getcwd.c I find the following comment: > > The Gnulib documentation > https://www.gnu.org/software/gnulib/manual/html_node/getcwd.html > points to the specification. That's usually a more

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

On Wed, 6 Mar 2024 at 20:09, Paul Smith wrote: > 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

Does gnulib getcwd always allocate if buf is NULL?

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 from the code, it always allocates if BUF is NULL. I assume this is

Re: Could `gnulib-tool` check for gjoin?

On Wed, 6 Mar 2024 at 17:07, Bruno Haible wrote: > Reuben Thomas wrote: > > > Such info could be added to the Gnulib manual. > > > > I doubt that would help many users (why should they read the gnulib > manual > > just to build software?) > > OK. In

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 22:23, Reuben Thomas wrote: > > I'm asking to have a workaround for each program that gnulib uses in one > place (in gnulib) rather than have every user of every package who wants to > build from git on macOS have to add the PATH workaround, which is the sort

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 21:47, Bruno Haible wrote: > > The programs are also in a libexec/gnubin/ directory, as symlinks, without > the 'g' prefix. See [1] line 80 and [2] line 39. > Indeed. So, it seems to me that it is simpler to ask the users to put this > libexec/gnubin/ directory in front of

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 19:06, Bruno Haible wrote: > > When people install the coreutils through Homebrew, which prefix do the > programs have by default? Is it "g", or is it none? > There seem to be two different ways: either with no prefix (e.g. m4), or with `g` prefix (e.g. coreutils); in both

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 18:51, Bruno Haible wrote: > > The habit of installing GNU coreutils with --program-prefix=g was common > on OSes like Solaris and *BSD, when people wanted to do serious development > on these platforms. But nowadays, why would anyone choose to do their > development on

Could `gnulib-tool` check for gjoin?

Now that gnulib checks that `join` is working, could it also try `gjoin` as a fallback, in the same way that other tools are searched for with a `g` prefix, e.g. `glibtoolize` and `gxargs`? -- https://rrt.sc3d.org

mkdir-p

Hi, I just tried to use this function and gave up. I appreciate that it is carefully written to cope with a wide variety of situations, but at present it looks more like the innards of something else (which indeed it appears to be, I see it in coreutils's mkdir!) rather than a reusable function

Re: gnu-web-doc-update doesn't work when the manual isn't already online

On Thu, 23 Mar 2023 at 13:24, Bruno Haible wrote: > > What I mean is that when a developer has removed or renamed some info nodes > in the documentation, previously existing HTML pages no longer exist. > Last time this happened, for example, after restructured the regular > expressions >

Re: gnu-web-doc-update doesn't work when the manual isn't already online

On Wed, 22 Mar 2023 at 05:42, Bruno Haible wrote: > > If we do this unconditionally, the user will get a warning message > > cvs add: manual/CVS already exists > > in the update case. This patch should thus work better. > Thanks for the improvement! > Btw, I prefer to not use this script,

gnu-web-doc-update doesn't work when the manual isn't already online

I spent a while trying to work out why I was getting CVS errors from the script for GNU a2ps, and I realised that the problem was that a2ps's manual wasn't online yet. This causes confusing error messages when the "manual" subdirectory isn't online, and cvs can't find a CVS directory and hence

Re: Cannot build fstat.c on mingw

On Sun, 26 Feb 2023 at 19:17, Bruno Haible wrote: > So, the cause could be that you are using a different version of mingw. > You might not be the only one. Therefore it would be useful if you could > analyze this failure. Then, let's see what is the best way forward (in > Gnulib and in

Re: License of module "Perl" seems wrong

On Mon, 27 Feb 2023 at 14:05, Bruno Haible wrote: > Hi Reuben, > > Reuben Thomas wrote: > > The perl module has a GPL license, but its only file, m4/perl.m4, has an > > "unlimited" license. > > The license of a module, in the module description, cannot be &qu

License of module "Perl" seems wrong

The perl module has a GPL license, but its only file, m4/perl.m4, has an "unlimited" license. -- https://rrt.sc3d.org

Cannot build fstat.c on mingw

I get an error with compiling: In file included from fstat.c:52: stat-time.h: In function ‘get_stat_atime_ns’: stat-time.h:52:43: error: invalid use of undefined type ‘const struct _stati64’ 52 | # define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim) and lots more the same. I came across this

Re: iconv module should detect buggy glibc iconv

On Sun, 19 Feb 2023 at 00:58, Bruno Haible wrote: > Reuben Thomas wrote: > > See https://sourceware.org/bugzilla/show_bug.cgi?id=29913 > > > > This is a bug I just came across (in my capacity as maintainer of Recode) > > in current glibc. > > > > glibc ic

iconv module should detect buggy glibc iconv

See https://sourceware.org/bugzilla/show_bug.cgi?id=29913 This is a bug I just came across (in my capacity as maintainer of Recode) in current glibc. glibc iconv(3) can return EILSEQ when the input is merely untranslatable, rather than invalid. This is directly contrary to the POSIX spec[1],

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

On Sat, 11 Feb 2023 at 12:40, Corinna Vinschen wrote: > On Feb 11 12:29, Reuben Thomas wrote: > > On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen > wrote: > > > > > > > > If you're sure that the native recode.dll has been built, is it > possible >

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen wrote: > > If you're sure that the native recode.dll has been built, is it possible > that it's just not found, because it's not in Windows' DLL search path? > > Yes, because it was working fine before, and I've not changed anything about where it

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

On Fri, 10 Feb 2023 at 14:21, Bruno Haible wrote: > It complains about the symbols defined in libiconv. This means, you need > to invoke the Gnulib module 'iconv' and add $(LIBICONV) or $(LTLIBICONV) > to the LDFLAGS. > Bruno to the rescue again! Many thanks. Having added the iconv gnulib

Re: x-to-1

On Sat, 11 Feb 2023 at 09:05, Bruno Haible wrote: > The package name doesn't change that often. (Although, for 'recode', it > already changed 3 times: recode → GNU recode → Free recode → recode.) > It may just be me, but I've renamed packages myself often enough, and then failed to find

Re: x-to-1

On Sat, 11 Feb 2023 at 08:48, Bruno Haible wrote: > I got the impression that without a .x file, the NAME section of the output > is too silly. > > This is correct, but although (as you observe) this means that some documentation goes in the Makefile.am, it avoids repeating the name of the

Re: x-to-1

On Thu, 9 Feb 2023 at 02:49, Bruno Haible wrote: > > > > In general, then, it would be good if x-to-1 ignored unknown options and > > passed them to help2man; would that be possible? > > Passing down additional options to help2man is a very good idea; > implemented > below. Ignoring unknown

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

On Tue, 7 Feb 2023 at 15:22, Corinna Vinschen wrote: > In Cygwin projects using libtool, we always have to add -no-undefined > iLDFLAGS. This is some old safe-guard in libtool to remind developers > that when creating Windows DLLs, all external symbols must be resolved. > > Fortunately, libtool

x-to-1

I just found this handy script while puzzling over various problems with help2man. In particular, it tests for cross-compilation, and copes with help2man missing. There are a couple of minor nits compared with direct usage of help2man, however: 1. Before, I passed --locale=en_US.UTF-8 so I could

Re: [PATCH] Do not decorate symbols as dllexport on Cygwin

On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote: > 1. 'recode' is updated to a current gnulib and publish a corresponding > tarball. (Hi Reuben :) ) > I've updated gnulib in recode git; I'd be grateful if I could have a report that it's doing what's needed here before I make a release,

build-aux/po/Makefile.in.in needs updating

Bruno pointed out to me that there's a bug fixed in the Makfile.in.in from gettext 0.20.2, which postdates the 0.20 version found in gnulib. (The bug is that the Makefile.in.in has prerequisites on suffix rules, which are ignored.) -- https://rrt.sc3d.org

relocatable-prog nits

Bruno has been helping me test https://github.com/rrthomas/libpaper on various systems. (Many thanks, Bruno!) On Wed, 1 Feb 2023 at 12:39, Bruno Haible wrote: > On GNU/Hurd and Cygwin, I see 9 test failures. Such as > > --- expected-fixed.txt 2023-02-01 03:02:44.0 +0100 > +++

Re: maint.mk: announcement should not be emailed to the TP when there are no changes

On Sat, 4 Feb 2023 at 21:18, Simon Josefsson wrote: > > To automatically understand if a cc to the translation project is > necessary or not, I think we'd need access to the previously sent pot > file, no? I guess we could wget that from somewhere and compare it, but > that seems a bit fragile.

maint.mk: announcement should not be emailed to the TP when there are no changes

I am maintaining a2ps, and have recently been making frequent alpha releases as I attempt to stabilise the result of a massive updating effort after a long period of quiescence. The most recent release involves no changes to the gettext strings. Using the standard gnulib release procedure for

Re: Using relocatable-script in a GPLv2-only program

On Tue, 1 Nov 2022 at 22:24, Bruno Haible wrote: > > But first, the obligatory question: Can't you move the package to GPLv2+? > As you guessed, I can't (though it might be possible to get the original authors to, I haven't asked). > That's what would be most in line with GNU policies, since

Using relocatable-script in a GPLv2-only program

I am working on my new version of libpaper, collaborating with a Debian maintainer to get it into Debian. This has thrown up some licensing issues, most of which I have been able to resolve, thanks to gnulib's flexible licensing options. I have one remaining problem: I use a legacy script from

Re: Using sc_po_check with --po-base

On Tue, 9 Aug 2022 at 10:26, Simon Josefsson wrote: > > I add the gnulib directories to the corresponding > exclude_file_name_regexp--sc_... entries in my cfg.mk, does that work > for you? Perhaps gnulib-tool could generate a gnulib.mk (included by > maint.mk) that add the appropriate sc_...

Using sc_po_check with --po-base

As suggested in the gnulib manual, I have converted a project (GNU a2ps) to use --po-base[=po-gnulib] and --po-domain, allowing gnulib to create an extra message catalog for gnulib sources. So, I have removed the gnulib files from po/POTFILES.in. However, sc_po_check in maint.mk now complains

Re: regex documentation

On Wed, 11 May 2022 at 22:22, Reuben Thomas wrote: > > Yes. I'll revise the patch. > Patch updated, now with correct (I hope!) documentation for \s and \S, modeled on that for \w and \W. (And with Bruno's stray comma removed.) -- https://rrt.sc3d

Re: regex documentation

On Wed, 11 May 2022 at 21:49, Paul Eggert wrote: > On 5/11/22 11:09, Reuben Thomas wrote: > > Sorry, I don't follow. The concrete example given is: \Sw matches any > > character that is > > not word-constituent. That seems to be [^[:alnum:]]? > > In glibc regex, \Sw

Re: regex documentation

On Wed, 11 May 2022 at 18:25, Paul Eggert wrote: > > Sorry, I should have been more specific. In glibc regex, \s is a synonym > for [[:space:]] and \S is a synonym for [^[:space:]], so the discussion > in regex.texi of @samp{\s@var{class}} etc. is wrong on a syntactic level > not just a semantic

Re: #ifdef emacs

On Wed, 11 May 2022 at 17:37, Paul Eggert wrote: > On 5/11/22 03:27, Reuben Thomas wrote: > > Mostly in alloca.c, with one case in parse-datetime.y. > Bruno handled alloca.c, and I did parse-datetime.y with the attached. > Thanks for reporting it. Thanks! I never cea

Re: regex documentation

On Wed, 11 May 2022 at 17:26, Paul Eggert wrote: > > Only thing I spotted offhand was that \s and \S mean something entirely > different in glibc as syntax classes are not programmable. > I think the documentation as I've edited it is correct. Perhaps it should say "character classes" instead

Re: regex documentation

On Wed, 11 May 2022 at 12:18, Bruno Haible wrote: > Reuben Thomas wrote: > > > I'm happy to prepare a patch in this case. I would simply remove all > > > mention of syntax tables, as that functionality is no longer available. > > > > Attached. > > Thanks!

Re: regex documentation

On Wed, 11 May 2022 at 09:15, Reuben Thomas wrote: > > I'm happy to prepare a patch in this case. I would simply remove all > mention of syntax tables, as that functionality is no longer available. > Attached. Here's the commit message to explain what I've done: Remove men

#ifdef emacs

Working on the regex documentation, I scanned gnulib for "#ifdef emacs", and found some instances (though not in the regex code). Should they be there? Mostly in alloca.c, with one case in parse-datetime.y. As far as I can see these are "native" gnulib modules, not maintained in sync with code

Re: regex documentation

On Wed, 11 May 2022 at 03:11, Bruno Haible wrote: > > I'd suggest to keep it. If we don't have time for a deep overhaul: please > just tell me which nodes of [1] have inaccurate information, and I'll add a > big warning "Note: The information on this page is out-of-date!" in each. > I would

Re: regex module has dropped support for syntax tables

On Wed, 11 May 2022 at 02:01, Paul Eggert wrote: > > > Failing that, you could also try GNU Emacs's regex implementation, which > >> is derived from GNU regex 0.12, and which may have fewer bugs than regex > >> 0.12. > > > > > > That's a good suggestion I hadn't thought of, thanks. I had a look

Re: regex module has dropped support for syntax tables

On Mon, 9 May 2022 at 20:29, Paul Eggert wrote: > On 5/8/22 15:54, Reuben Thomas wrote: > > > I sympathise if the gnulib maintainers don't want to reintroduce them; in > > that case, could their removal please be flagged up in the docs? > > Sure, I installed the attac

Re: regex module has dropped support for syntax tables

On Mon, 9 May 2022 at 02:53, Bruno Haible wrote: > Reuben Thomas asked: > > Also, do the maintainers have any better suggestion for what I should do > > than revert to GNU regex 0.12 for a2ps? > > AFAIU, regex syntax tables assume a 7-bit or 8-bit text encoding. But >

regex module has dropped support for syntax tables

I am working on GNU a2ps. I have tracked down a test failure to the lack of support for syntax tables in gnulib's regex module (removed by commit 151e40bb39 which switches from GNU regex 0.12 to the glibc version). This took me quite a long time to work out, since syntax tables are still

Re: rpl_free undefined

On Tue, 3 May 2022 at 03:24, Bruno Haible wrote: > > OK, so our effort from April 2021 to June 2021 fixed the problem; > recall that you initiated that through > . > OK, I will try to remember to make it an iron rule that I

Re: rpl_free undefined

On Mon, 2 May 2022 at 02:02, Bruno Haible wrote: > > I don't want to debug a gnulib version from more than 1 year ago, therefore > I'm using >./bootstrap --skip-git --gnulib-srcdir=$GNULIB_SRCDIR > (Argh. Why is this option not called --no-git, like in the other > 'bootstrap'?) > > Then I

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Mon, 2 May 2022 at 01:05, Bruno Haible wrote: > > We have documented hundreds of deficiencies of mingw [1] w.r.t. the POSIX > standard. MSYS is surely worse, not better, than mingw. I recommend to use > the respective modules, for those POSIX APIs that you use. > I'm happy to decide that on

Re: rpl_free undefined

On Sun, 1 May 2022 at 22:39, Bruno Haible wrote: > A link error is not a "minor" problem; it's a major one. > > More generally: How to reproduce? > Check out https://github.com/rrthomas/libpaper.git commit 8fe608f on MSYS Edit bootstrap.conf to remove the posix-free module ./bootstrap

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Sun, 1 May 2022 at 22:34, Bruno Haible wrote: > Reuben Thomas wrote: > > It's not really that I'm doing anything: gnulib seems to detect MSYS as > > being a POSIX platform. > > Not really; something in the configure step (which you haven't shown) > made it "detect

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Sat, 30 Apr 2022 at 12:44, Bruno Haible wrote: > Reuben Thomas wrote: > > on MSYS it goes wrong > > ... > > setlocale_null_with_lock (category=category@entry=0, buf=buf@entry > =0xbd80 > > "", bufsize=bufsize@entry=3221) at setlocale_null.c:228 >

setlocale with NULL locale (to read current locale) segfaults on MSYS

It works fine on mingw32 and mingw64, but on MSYS it goes wrong when calling pthread_mutex_lock. In the following gdb session, the first line is from my code; the rest is tracing through gnulib code. (gdb) n 171 char *old_locale = setlocale(LC_ALL, NULL); (gdb) s rpl_setlocale

Misleading --help for git-version-gen

Just noticed that it says: "Running without arguments will suffice in most cases." However, there is a mandatory argument! -- https://rrt.sc3d.org

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Thu, 20 Jan 2022 at 13:24, Ryan Schmidt wrote: > If gnulib starts requiring a compiler newer than Apple gcc 4.2.1, that will > be problem for MacPorts on 10.6 and earlier. We might be able to bootstrap > our way to a newer compiler, but that wouldn't be possible if the newer > compiler or

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote: > > If you are OS X 10.8 and above, then you will likely be using Apple > Clang (or LLVM Clang), and you likely won't have troubles. > > OS X 10.6 switched to llvm-gcc. It should not have a problem with > inline.

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 18:38, Paul Eggert wrote: > > I'm not sure a newer compiler would fix the bugs, as they're typically > present in the ctype.h supplied by the OS. If the newer compiler comes > with a fixed ctype.h you're OK; if it reuses or copies the old ctype.h > you'll have a problem. I

Re: Broken "make distcheck" with automake 1.16

On Tue, 18 Jan 2022 at 14:51, Bruno Haible wrote: > > This has been fixed on 2022-01-08. Many thanks, sorry for the noise! -- https://rrt.sc3d.org

Broken "make distcheck" with automake 1.16

Building Recode[1], which uses a recent gnulib (commit 035ce56a33 of 5th January 2022), I find that when I run "make distcheck", some .deps/*.Plo files generated by the build are not removed by any clean rule, leading "make distcheck" to report: ERROR: files left in build directory after

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 01:58, Ryan Schmidt wrote: > MacPorts itself still runs on Mac OS X 10.4 and later and we do still have a > number of users using older systems. More so than with other operating > systems, I think, Mac users care about support for older OS versions because > Apple

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 22:22, Reuben Thomas wrote: > > On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote: > > > > Although the workaround still functions on current macOS, it's better to > > use proper inline functions when available so I installed the attached > >

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote: > > Although the workaround still functions on current macOS, it's better to > use proper inline functions when available so I installed the attached > patch into Gnulib. Please give it a try. Thanks, I will. > I don't know whether the macOS

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 17:41, Paul Eggert wrote: > > Could you give complete instructions from scratch, to reproduce the > config.h that has this problem? Without that, it'll be hard for us to > understand or fix the problem. Sorry, I've failed to explain the problem clearly (or maybe there's a

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 12:37, Bruno Haible wrote: > > Please, to help us reproduce the issue and verify a potential fix: > How to reproduce the issue? I.e. What did you try to do, and what were > the resulting diagnostics? $ gcc -dM -E config.h | grep GL_EXTERN #define _GL_EXTERN_INLINE static

_GL_EXTERN_INLINE not defined correctly in config.h for macOS

The definition of _GL_EXTERN_INLINE relies, on macOS, on __header_inline, which is not a compiler built-in, but is defined in sys/cdefs.h. Therefore, __header_inline is not defined when config.h is included, and the tests always assume, on macOS, that the compiler is buggy and does not support

Re: Interference between two installations of gnulib

On Sun, 11 Apr 2021 at 20:32, Bruno Haible wrote: > > Having two separate configure scripts is undesirable, because that would > increase the total configure time of the package (and people have already > complained about the configure time). > > The same problem is seen also in GNU gettext and

Interference between two installations of gnulib

I have made two installations of gnulib in a project, because I am using both relocatable-prog and relocatable-lib-lgpl. I have different modules installed for each, of course. I just had a problem where my library would not compile, because it was missing setlocale_null.h. GNULIB_SETLOCALE_NULL

Typo in relocatable-maint.texi?

In the following text, describing how to use multiple gnulib installations: Correspondingly for the programs you will have to add something like this: ... AM_CPPFLAGS = -I$(top_srcdir)/src/gnulib -I$(top_builddir)/src/gnulib ... LIBADD =

Re: Using relocatable-prog with relocatable libraries

On Fri, 9 Apr 2021 at 11:18, Reuben Thomas wrote: > On Fri, 9 Apr 2021 at 02:41, Ben Pfaff wrote: > >> Do you think it should be better documented, or documented somewhere >> else? (I'm only getting to my email now.) >> > One practical reminder that would be useful

Re: Using relocatable-prog with relocatable libraries

On Fri, 9 Apr 2021 at 02:41, Ben Pfaff wrote: > On Mon, Apr 5, 2021 at 3:43 PM Reuben Thomas wrote: > > > > On Mon, 5 Apr 2021 at 23:36, Reuben Thomas wrote: > >> > >> > >> The comment about "all the copies of relocatable.c" in progreloc.c

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 23:36, Reuben Thomas wrote: > > The comment about "all the copies of relocatable.c" in progreloc.c is > surely is clue, but I cannot see how more than one copy of relocatable.c is > ever compiled… > Finally found, in relocatable-maint.texi, &

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 22:55, Reuben Thomas wrote: > > Have I missed something? I was surprised that I hadn't come across this > problem before, but I found that I've used relocatable-lib-lgpl before, but > not relocatable-prog (because in fact I was working with an LGPL

Using relocatable-prog with relocatable libraries

I use relocatable-prog in a project which builds a binary that links against a library which itself is installed publicly. Therefore, I build gnulib with -DIN_LIBRARY. This causes gnulib to be built with a static copy of compute_curr_prefix, named local_compute_curr_prefix. Therefore, when

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 10:06, Bruno Haible wrote: > Hi Reuben, > > > Unfortunately, this doesn't help, because pathconf is not present on > mingw. > > Then use some fallback, e.g. 256 or PATH_MAX. > > > So the best I can do is #define _POSIX_ to get the value of NAME_MAX that > > it has. > >

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:16, Reuben Thomas wrote: > On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > >> Hi Reuben, >> >> > NAME_MAX is defined in limits.h. >> >> No. POSIX [1] specifies that it may be omitted from , and >> that pathconf (_PC_NAM

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > > I don't see anything Gnulib should do here. > Having looked into this, it seems that the same issues apply to PATH_MAX, yet gnulib has a pathmax module to define PATH_MAX. What's different in that case? -- https://rrt.sc3d.org

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > Hi Reuben, > > > NAME_MAX is defined in limits.h. > > No. POSIX [1] specifies that it may be omitted from , and > that pathconf (_PC_NAME_MAX) is the right way to access the maximum > length of a file name component. [2] > Ah, thanks for

NAME_MAX on MingW

NAME_MAX is defined in limits.h. And indeed it is there on Mingw, but guarded by the Windows-specific non-standard macro _POSIX_. I found this suggestion that Windows system headers have not used _POSIX_ since MSVC 2013: https://sourceforge.net/p/mingw-w64/mailman/message/33014416/ However, the

Re: Example use of manywarnings could be updated

On Sun, 7 Mar 2021 at 21:49, Paul Eggert wrote: > On 3/7/21 6:04 AM, Reuben Thomas wrote: > > I think leaving just -Wsystem-headers in the list would be fine, as it's > a > > good example where opinions differ on what's desirable, and is unlikely > to > > be added to t

Example use of manywarnings could be updated

The example: @smallexample gl_MANYWARN_ALL_GCC([warnings]) # Set up the list of the pointless, undesired warnings. nw= nw="$nw -Wsystem-headers" # Don't let system headers trigger warnings nw="$nw -Wundef"# All compiler preprocessors support #if UNDEF nw="$nw -Wtraditional"

Re: Computing `cur_prefix_arg` argument to `set_relocation_prefix`

Apologies, I see that relocatable-prog actually already covers what I'm trying to do with progreloc.c. Sorry for the noise!

Re: Computing `cur_prefix_arg` argument to `set_relocation_prefix`

On Sat, 30 Jan 2021 at 18:25, Reuben Thomas wrote: > > 1. Have I overlooked a simpler method of computing `cur_prefix_arg`? > Whether or not there is a simpler way, it would be good to have this > functionality included in the relocatable-prog gnulib module. > In particular,

Computing `cur_prefix_arg` argument to `set_relocation_prefix`

I'm using the relocatable-prog module, and assuming that my program may be running on a platform that needs to call `set_relocation_prefix`. Therefore, I need to compute the `cur_prefix_arg`. I assume that the program is installed with the standard directory layout under some prefix. To compute

Re: relocatable.texi: improve reference to packaging systems?

On Tue, 26 Jan 2021 at 16:40, Bruno Haible wrote: > Reuben Thomas wrote: > > If you still don't agree, then I suggest: "The package systems of most > > GNU/Linux distributions." > > The same problem exists for distros on macOS (MacPorts, Fink, ...), Solaris &

Re: relocatable.texi: remove mention of OpenBSD?

On Tue, 26 Jan 2021 at 09:36, Bruno Haible wrote: > Hi Reuben, > > > doc/relocatable.texi contains the following text: > > > > > > > Also, installation with > > > @option{--enable-relocatable} might not work on OpenBSD, when the > > > package contains shared libraries and libtool versions

Re: relocatable.texi: improve reference to packaging systems?

On Tue, 26 Jan 2021 at 09:43, Bruno Haible wrote: > Hi Reuben, > > > Rather than > > > > Red Hat, Debian, and similar package systems > > > > > > > would it make more sense to refer to > > > > "RPM, APT, and similar package systems" > > > > ? (i.e. refer to the package systems, not the GNU/Linux

relocatable.texi: improve reference to packaging systems?

Rather than Red Hat, Debian, and similar package systems > would it make more sense to refer to "RPM, APT, and similar package systems" ? (i.e. refer to the package systems, not the GNU/Linux distros). -- https://rrt.sc3d.org

  1   2   3   4   5   6   >