test suite failure caused by check-copyright script

Hello! I'm discovering this project and attempted to run 'make check'. It seems to be finding problems, failing with: --8<---cut here---start->8--- [...] GPL?? lib/xstrtoull.c GPL?? lib/xstrtoumax.c GPL

Re: can't compile `stdlib.h` on mxe

>> 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

Re: sigsegv.h interface

On 5/22/21 5:00 PM, Bruno Haible wrote: it is possible to move forward with the API of sigsegv.h faster in Gnulib than it is possible in libsigsegv. Yes, that was the path I was assuming. But please hold off from doing this patch for now. Will do.

Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34

On 5/22/21 3:59 PM, Bruno Haible wrote: Now, you are arguing "let's ignore whether programs use nested functions". Not at all. All I'm saying is, stack-overflow handlers shouldn't call via pointers to nested functions. There are already several restrictions on stack-overflow handlers; for

stdio: Fix compilation error on DragonFly BSD

Building a testdir on DragonFly BSD 6.0, I see this error: In file included from ../../gltests/test-stdio-c++.cc:22: ../gllib/stdio.h: In member function 'gnulib::_gl_fcloseall_wrapper::operator gnulib::_gl_fcloseall_wrapper::type() const': ../gllib/stdio.h:755:1: error: invalid conversion from '

Re: sigsegv.h interface

Hi Paul, I wrote: > >- The declaration in sigsegv.h needs to stay, at least for the next > > couple of years, because it is necessary for programs that use SIGSTKSZ > > (such as GNU m4 and GNU clisp) to compile fine. > > Why is it needed for GNU m4 and GNU clisp? I just looked at th

Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34

Hi Paul, What you are doing now is to deconstruct - GCC extensions, and - POSIX. 1) Regarding GCC extensions: > > malloc'ed memory is not executable. But GCC's trampolines (used by nested > > functions) require an executable stack. When an object file has such nested > > functions, the toolc

Re: Fwd: Port getprogname module to Tru64

Thanks, I installed that in your name.

Re: can't compile `stdlib.h` on mxe

On 5/22/21 7:32 AM, Bruno Haible wrote: 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"

Re: can't compile `stdlib.h` on mxe

>> 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

Re: Fwd: Port getprogname module to Tru64

On 2021-05-22 10:52, Bruno Haible wrote: > This patch was mangled by your mailer. Please send patches as attachments > to the mail, not inline in the mail. > > Bruno > Sure. I've attached the patch, which is working in my testing. Larkin --- a/lib/getprogname.c 2021-05-22 02:27:02.835632

Re: Fwd: Port getprogname module to Tru64

Hi, Larkin Nickle wrote: > > This patch allows getprogname to work under Tru64. This has been tested > > on Tru64 5.1B-6 with success. Tru64 is unsupported by gnulib, see If you provide patches that work an

Re: can't compile `stdlib.h` on mxe

Hello Werner, > 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. > > * Can you verify that ddlineedit.moc.cpp starts with a '

Re: Fwd: Port getprogname module to Tru64

On 2021-05-22 02:40, Larkin Nickle wrote: This patch allows getprogname to work under Tru64. This has been tested on Tru64 5.1B-6 with success. Larkin ... Oops, the last patch has a bad header. This should be fixed. :) Larkin --- a/lib/getprogname.c 2021-05-22 02:27:02.835632500 -0

Fwd: Port getprogname module to Tru64

This patch allows getprogname to work under Tru64. This has been tested on Tru64 5.1B-6 with success. Larkin --- lib/getprogname.c 2021-05-22 02:27:02.835632500 -0400 +++ lib/getprogname.c.patched 2021-05-22 02:33:55.003154200 -0400 @@ -43,7 +43,7 @@ # include #endif -#ifdef __sgi +#if

Re: can't compile `stdlib.h` on mxe

Hi Werner, > 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, >

can't compile `stdlib.h` on mxe

[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,