> I haven't been able to find out precisely which versions produce the
> warning, by looking at https://github.com/apple/llvm-project . So,
> I'm applying the conservative patch: [...]
Thanks! Maybe other Apple users chime in so that the test can be
refined if necessary.
Werner
This snippet
```
#include
int main(int argc, char* argv[])
{
switch(argc)
{
case 3:
puts(argv[2]);
__attribute__((fallthrough));
case 2:
puts(argv[1]);
__attribute__((__fallthrough__));
case 1:
puts(argv[0]);
/* fall through */
>> maybe you should define a couple of macros like
>> GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER
>
> I hope we don't need to do that. This is software archaeology (Mac
> OS X 10.7.5 is so old that neither the Subject: line nor my patch
> got its name right, and nobody mentioned the mistake
>> All source code files that I can control (`maingui.moc.cpp`,
>> `maingui.h`, `ddlineedit.h`) start with `#include `.
>
> Ah, right, you can't fully follow the gnulib requirement,
> because of Qt's 'moc'.
>
> I'm committing this patch. Hope it helps.
It helps, thanks!
Werner
inition
```
All source files either start with `#include ` or include
other local header files that load `config.h` as the very first
thing.
Werner
// maingui.h
// Copyright (C) 2012-2022 by Werner Lemberg.
//
// This file is part of the ttfautohint library, and may only be use
[66c5e7dd3aa58bde7a928867a763bf7e11206c93]
Without changing my source code (https://repo.or.cz/ttfautohint.git)
or the compiler (gcc 7.5.0), an update of gnulib from 2021-08-07 to
2021-01-13 suddenly produces a bunch of new, identical warnings on my
openSUSE Leap 15.2 GNU/Linux box, which look l
[Please CC me; I'm not on the list.]
I wrote
For example, in my project I would like to call the script as
prefix-gnulib-mk --lib-name=libgnu gnulib/src/$gnulib_mk
I suggest a patch as below (which needs further polishing to
properly canonicalize the directory path, I guess).
and P
[c7b1e060d17023065c776757da406d728310cc38]
Dear gnulib maintainers,
Currently, the script `prefix-gnulib-mk` replaces variables like
`libbison_a_SOURCES` with `lib_libbison_a_SOURCES`. However, this
works only if the directory is indeed `lib/', which is not the general
case. For example, in
>> It doesn't – it is an auto-generated Qt file. However, the file
>> starts
>> with
>> ```
>> #include
>> #include "ddlineedit.h"
>
> You could instead compile a file ddlineedit.config-moc.cpp, with the
> following contents:
>
> #include
> #include "ddlineedit.moc.cpp"
Yeah, this came to my
>> Note that this is a new error; it didn't happen in July 2019 (the
>> last time I've tried to build ttfautohint with mxe and Qt5).
>
> Yes. We have added 'restrict' in many places, to match the function
> declarations in POSIX.
OK.
> That's not enough. needs to be included before .
>
> The
[9c4b4b083f87]
While compiling my `ttfautohint` package with a slightly tailored mxe
build, I get the following compilation error:
CXX ttfautohintGUI-ddlineedit.moc.o
In file included from
/home/wl/git/mxe/usr/lib/gcc/i686-w64-mingw32.static/5.5.0/include/c++/cwchar:44:0,
s/performace/performance/
Werner
The attached patch fixes all overfull lines except the ones caused by
overlong URLs.[*] I've tested it with texinfo 6.5 – I hope using
@inlinefmt (introduced 2013 in version 5.0) is OK.
Werner
[*] The @url command produces overfull lines even if within a
@raggedright environment. I c
> OK, here's what I'm committing: the same idiom as we use for
> wint_t. [...]
Thanks!
Werner
>> +} _gl_max_align_t;
>> +#define max_align_t _gl_max_align_t
>> #endif
>> # endif /* _@GUARD_PREFIX@_STDDEF_H */
>> This one is not brittle and is not a big change. If Paul agrees, I
>> would commit this, and you (Werner) would not need to reorganize
>> your package's configuration.
>
>
>> > Could you try incorporating the std-gnu11 module into your
>> > package, and see whether that fixes things? If so, perhaps we
>> > could fix this problem for everybody by having stddef depend on
>> > std-gnu11.
>>
>> This approach worked
>
> Nevertheless, I don't agree that this is the solu
> Could you try incorporating the std-gnu11 module into your package,
> and see whether that fixes things? If so, perhaps we could fix this
> problem for everybody by having stddef depend on std-gnu11.
This approach worked, cf.
https://travis-ci.org/source-foundry/ttfautohint-build/builds/271
From: Bruno Haible
Subject: Re: bootstrap fails on Darwin for `libtool'
Date: Sat, 19 Nov 2016 17:01:31 +0100
> The background appears to be that on macOS:
> * /usr/bin/libtool is an Apple program, that does not support the GNU
> interface. It comes with Xcode; Xcode is the usual way to ins
>> configure:17517: gcc -c
>> -I/Users/travis/ttfautohint-build/local/include -g -O2 conftest.c >&5
>> conftest.c:145:13: error: use of undeclared identifier 'max_align_t'
>
> Evidently the stddef.h found by the above command does not define
> max_align_t, whereas the stddef.h found by the comman
>>checking for max_align_t... no
>
> Why did this say "no" even though stddef.h evidently defines
> max_align_t? Please look for details in config.log.
Below. For reference you can also find the complete `config.log' file
attached.
Werner
=
Building ttfautohint (http://repo.or.cz/ttfautohint.git/) on OS X
10.10 (XCode 6.4) fails. The data below is taken from a travis build
(https://travis-ci.org/source-foundry/ttfautohint-build/jobs/269031319#L3401).
Here's the list of the gnulib modules I use in ttfautohint:
dirname
fcntl-h
Folks,
I got the following report for groff
https://savannah.gnu.org/bugs/?49651
The groff build from repository source fails in the ./bootstrap
phase on MacOS X systems. GNU libtool conflicts with the Xcode
libtool. The attached patch [below] checks for a Darwin build and
uses glib
> Yes, that sounds right. I installed the attached patch into Gnulib,
> which should work around the problem there. Presumably something
> similar can be installed into FreeType.
Done. Thanks a lot for your help!
Werner
> Generally speaking the compiler warnings you're talking about cause
> false alarms so often that they're more trouble than they're worth.
> For example, if P and Q are pointers into the same array and P <= Q,
> it's quite normal to compute Q-P and store the result into a size_t
> variable.
No q
son of integers of different signs:
'int' and 'size_t' (aka 'unsigned int') [-Wsign-compare]
if (count < maxlen
~ ^ ~~
I have no idea how much you want to `uglify' the sources...
Werner
>From 40c8e8993
> I suggest disabling the unwanted diagnostic instead. Something like
> this at the start of the file:
>
> #if 4 < __GNUC__ + (3 <= __GNUC_MINOR__)
> # pragma GCC diagnostic ignored "-Wformat-extra-args"
> #endif
This is better, thanks. However, I'm not happy to globally disable
the warning.
>> #if _LIBC
>> - __fxprintf (NULL, file_name != NULL ? "%s:%d: " : " ",
>> - file_name, line_number);
>> + if (file_name != NULL)
>> +__fxprintf (NULL, "%s:%d: ", file_name, line_number);
>> + else
>> +__fxprintf (NULL, " ");
>
> The new version is less efficient becaus
==
2014-11-05 Werner Lemberg
error: fix warning message
* lib/error.c (error_at_line): Always use correct number of
arguments for format string.
diff --git a/lib/error.c b/lib/error.c
index 18ff5db..d83cfb2
> I've tested it on MSYS after manually adding 'const' to the iconv
> declaration in /usr/local/include/iconv.h, and it seems to be
> detected.
>
> Here is a new test package:
> http://du-a.org/~ueno/junk/test-iconv-2.tar.gz
Thanks for your quick response; I've updated your patch in the groff
re
>> Looks good, thanks! Eli, do you have time to test it?
>
> If you commit the proceeds into the Groff repo, I could try testing
> tomorrow.
I've just committed Daiki-san's patch to the groff repository.
Thanks!
Werner
> The attached patch seems to work with both cases.
Looks good, thanks! Eli, do you have time to test it?
Werner
>> Given that the intention of the above test is to check if the iconv
>> function works properly, maybe a workaround would be to use the
>> fixed prototype of iconv (as attached)?
>
> Sorry, that was obviously wrong. The other idea is to suppress the
> error with a pragma, but I guess it would
Eli reported a failure in the detection code of iconv on MinGW while
building groff:
configure:9176: checking for working iconv
configure:9296: g++ -o conftest.exe -O0 -g3 -Id:/usr/include conftest.cpp
d:/usr/lib/libiconv.dll.a -Ld:/usr/lib >&5
conftest.cpp: In function 'int main()':
co
> It's a little tricky, since error doesn't need all of progname, just
> the one variable. I expect we need a stripped-down module just for
> that.
This might be so :-) However, I suggest a `progname' dependency as a
quick fix until a better solution gets implemented.
Werner
`error.c' references `program_name', so it needs the `progname'
module.
I found this the hard way, trying to compile a program with
the `mxe' toolchain that cross-compiles with mingw64...
Werner
>> The functions `base_name' and `dir_name' (or rather `mdir_name'),
>> intended as replacements for `basename' and `dirname' that work on
>> Windows also, are not documented in `gnulib.pdf'. I suggest to
>> mention those two function names at least in `modules/dirname'.
>
> I applied the followi
>> Here's a necessary patch for making `dirname' work with C++.
>
> Pushed.
Thanks!
Werner
Here's a necessary patch for making `dirname' work with C++.
Werner
==
diff --git a/ChangeLog b/ChangeLog
index 58a6511..9ac551d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-09-21 Wern
The functions `base_name' and `dir_name' (or rather `mdir_name'),
intended as replacements for `basename' and `dirname' that work on
Windows also, are not documented in `gnulib.pdf'. I suggest to
mention those two function names at least in `modules/dirname'.
Werner
> Pushed with the "C" guards also on the extern variables,
> since both extern functions and variables are subject
> to C++ linkage.
Thanks!
Werner
Werner
==
From: Werner LEMBERG
Subject: Re: strerror_r.c doesn't compile if CC=g++
Date: Tue, 25 Feb 2014 08:17:31 +0100 (CET)
>
> Ping!
>
>
> Werner
>
>
> ==
> Thanks, will a similar change be needed on HP-UX, IRIX, Solaris for
> "extern int sys_nerr;" later in that file?
I don't know, sorry.
> (Sorry, I'm not a C++ expert, but I figure you are so I'm asking
> you)
Hehe, I'm not an expert either :-) However, I think the `"C"' informs
the linker
Ping!
Werner
==
> [v0.1-78-g47f93b0]
>
> The following patch is necessary to make `strerror_r.c' compile if
> CC=g++. Similar code is already used for the autoconf test.
>
>
> Werner
>
>
> 1.00rc0
>
> Personally, when I see a version number like that, I'm never sure
> what it means. Probably the first rc leading up to 1.00, but maybe
> it is an rc for 1.01 after 1.00.
Well, I have *never* encountered that `1.00rc0' means a release
candidate for 1.01. Have you?
> And suffix
Folks,
I try to make a release candidate. Theoretically, I could use version
`0.99.99' or something similar, however, it looks much nicer IMHO to
use `1.00rc0'. Unfortunately, the gnits standard currently prevents
this. To be more precise, it's the following regex in the automake
script:
m
[v0.1-78-g47f93b0]
The following patch is necessary to make `strerror_r.c' compile if
CC=g++. Similar code is already used for the autoconf test.
Werner
==
diff --git a/lib/strerror_r.c b/lib/strerror_r.c
index 4aa96cb..
> Passed my tests, so I've now pushed it with this changelog (the tiny
> change designation merely means you don't have copyright papers on
> file for gnulib):
Thanks. However, IIRC, I've signed quite broad copyright papers many
years ago so that contributions to *any* GNU project are automatica
Some time ago I wrote:
> in my setup for ttfautohint (http://repo.or.cz/w/ttfautohint.git) I
> have the following assignment in `bootstrap.conf':
>
> build_aux=gnulib
>
> It seems that the patch below is necessary to make this really work
> (at least it works for me): if I understand the issu
[gnulib commit 68f90afdb82204c27a50e7bce169d2b3795a1ddd]
Folks,
in my setup for ttfautohint (http://repo.or.cz/w/ttfautohint.git) I
have the following assignment in `bootstrap.conf':
build_aux=gnulib
It seems that the patch below is necessary to make this really work
(at least it works for
It seems that the crypto stuff is completely undocumented; it would be
great if at least documentation templates are added for all the
functions and modules of gnulib.
Werner
Folks,
the default operation (a) of `bootstrap' is clear:
1. The `gnulib' submodule URL is in file `.gitmodules'.
2. No special submodule entry in `.git/config'.
3. A (submodule) clone of `gnulib' is created.
4. All files of `gnulib' are checked out.
If I already have a local `gnulib'
> Since then, I've broken out some functionality into reusable
> standalone scripts that will be useful for replacing the hairy
> sed-and-grep method of interrogating the m4 macros used by
> configure.ac with a much more robust and faster call to parse the m4
> macros with GNU M4!
Parsing m4 macro
>>> After doing the incantation described in section 2.8 of gnulib.pdf,
>>> namely
>>>
>>> $ dir=.gnulib
>>> $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>>>
>>> the user has to commit the submodule setup to the repository. It's
>>> probably worth to mention this.
>>>
>>> Howev
> Perhaps you could try my rewrite of the bootstrap script, with which
> I cannot reproduce the problem you describe?
Will do that eventually, thanks.
> I'm unsure how to proceed. On one hand, I like `.gnulib' as the
> submodule's directory. On the other hand, I don't like `.gnulib' as
> the s
> After doing the incantation described in section 2.8 of gnulib.pdf,
> namely
>
> $ dir=.gnulib
> $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>
> the user has to commit the submodule setup to the repository. It's
> probably worth to mention this.
>
> However, if I now say
>> . First of all, there is some user-unfriendliness: Without
>> installing a gnulib submodule for project `foo', just invoking
>> the `bootstrap' script in the `foo' directory' without any
>> arguments gives
>>
>> ./bootstrap: line 610: gnulib/gnulib-tool: No such file or directory
>>
[gnulib 530dd174]
The `git submodule' is a very nice feature, however, there are two
issues.
. First of all, there is some user-unfriendliness: Without
installing a gnulib submodule for project `foo', just invoking the
`bootstrap' script in the `foo' directory' without any arguments
>> I've invoked gnulib-tool as follows:
>>
>> gnulib-tool --import \
>> --m4-base=gnulib/m4 \
>> --source-base=gnulib/src \
>> --aux-dir=gnulib getopt-gnu
>>
>> and the recommendations emitted say this:
>>
>> Don't forget to
>> - add "lib/Makefile"
> I (and AFAIK, everyone who contributes regularly here) recommend
> *not* to version-control the files that gnulib-tool imports.
Good to know. What a relieve :-)
Thanks for the answer!
Werner
Folks,
the normal usage of gnulib is to import files into a project, this is,
calling `gnulib-tool --import', then adding the imported files to the
repository.
I wonder whether the step `adding files to the repository' is
necessary at all. Why not simply calling gnulib-tool directly in the
`au
[gnulib commit 60224129]
I've invoked gnulib-tool as follows:
gnulib-tool --import \
--m4-base=gnulib/m4 \
--source-base=gnulib/src \
--aux-dir=gnulib getopt-gnu
and the recommendations emitted say this:
Don't forget to
- add "lib/Makefile" to
> The differences between --create-testdir and --add-import are
> explained by their different use cases. [...]
>
> --create-testdir create a scratch package with the given modules
Mhmm, I had no idea what `scratch package' really means. To do
something `from scratch' normally means to st
[gnulib commit 64911207]
Comparing the contents of the gnulib directory created by
gnulib-tool --create-testdir \
--dir=src/libs/gl \
wcwidth
and
gnulib-tool --add-import \
--dir=src/libs/gl \
--source-base=gllib \
--m4-
[git 64911207]
The title says all. I consider this a serious bug.
Werner
[gnulib commit 64911207]
Doing
gnulib-tool --create-testdir --dir=src/libs/gl wcwidth
creates the following directory structure:
src/libs/gl/build-aux
src/libs/gl/gllib
src/libs/gl/glm4
However, doing
gnulib-tool --add-import --dir=src/libs/gl wcwidth
afterwards, I have two new di
Two suggestions to improve formatting of gnulib.pdf:
. To avoid thousands of overlong lines, replace
POSIX specification: @url{...}
with
POSIX specification:@*
@url{...}
I think this is beneficial even for the HTML version of the gnulib
documentation.
. The patch below (aga
> > What about adding a test to find out the extension of (static)
> > libraries? Having a LIBEXT variable would be quite helpful.
>
> [...] you can alternatively use the gnulib module havelib (which
> will use the logic in the config.rpath file to set libext).
This looks very promising, thanks!
From: [EMAIL PROTECTED] (Karl Berry)
Subject: Re: ftp.gnu.org no longer working with old method?
Date: Sat, 14 Oct 2006 16:30:12 -0500
> > About a week ago, the `gnupload' script (from gnulib) worked just
> > fine. Right now I get error messages like this
> >
> > no filename directive specified
> > In the files `getopt.c', `glob.c', and `regexprops-generic.texi' I
> > suggest to replace the word `illegal' with `invalid'.
>
> Not for getopt.c, since POSIX requires the word "illegal" there;
Uh, oh, thanks for the information.
Werner
___
[CVS 2006-02-24]
In the files `getopt.c', `glob.c', and `regexprops-generic.texi' I
suggest to replace the word `illegal' with `invalid'.
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
There isn't a file `modules/progreloc' which looks like a bug to me
since it depends on progname.
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
[CVS 2006-01-06]
The file localcharset.c asks for the preprocessor symbol
HAVE_DECL_GETC_UNLOCKED which doesn't get defined in the m4 files
listed in modules/localcharset.
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.or
During compilation with gcc 3.3.3 I get
localcharset.c:110: warning: function declaration isn't a prototype
maybe the `STATIC' hack as used for locale_charset is needed too...
Werner
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists
Compiling getopt.c I get these warnings from gcc:
getopt.c: In function `_getopt_initialize':
getopt.c:253: warning: unused parameter `argc'
getopt.c:253: warning: unused parameter `argv'
getopt.c:1159:5: warning: "_LIBC" is not defined
While harmless I think they could be removed by ad
> FWIW, the getopt version from 1998 needed the following patches to
> make in work in C++. Taken from GNU gperf. Maybe that might help
> you.
Thanks! Are these changes already incorporated into the current
getopt version of gnulib? Additionally I wonder about the differences
between glibc's
> - For programs that really don't want internationalization, you
> can add a file gettext.h in your source tree containing merely
>
> #define gettext(s) s
OK, this is a nice (temporary) idea I can live with, thanks!
Werner
___
bug
> > I think it is a *bad* idea to make getopt depend on gettext
> > unconditionally.
>
> Is this because groff uses getopt but not gettext?
Exactly. Adding gettext support to groff would be nice, but until now
it hasn't happened.
> What about the other gnulib modules that depend on gettext? He
I think it is a *bad* idea to make getopt depend on gettext
unconditionally. I suggest a patch similar to the one below.
BTW, Nelson Beebe tested a prerelease of groff 1.19.2 on his zoo of
Unix platforms. He writes:
Builds with C++ compilers fail in compiling getopt.c; it is too bad
that t
The following script files in the gnulib library have `#!/...' instead
of `#! /...' in the first line. According to the autoconf info files
this might cause problems on some old platforms. Today this is
probably no longer important, but I think it is a good idea to make
all shebangs in the vario
79 matches
Mail list logo
