Re: wget 1.21.1 fails to build on macOS (10.14, 10.15, 11.1)
Ah, yes, I see that your build uses the flag `--without-included-regex`.
That should probably take care of the build failure I'm seeing. Thanks
for the tip, Ryan.
The header of regex.c says it's part of glibc, though, so it's no
surprise that it leads to build failures on macOS. wget probably
shouldn't be using this on non-Linux platforms.
> On 25 Jan 2021, at 10:47, Ryan Schmidt wrote:
>
> On Jan 24, 2021, at 23:40, Carlo Cabrera wrote:
>
>> wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build
>> fails with a series of errors starting with
>>
>> In file included from regex.c:74:
>> In file included from ./regexec.c:1362:
>> ./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
>> __nonnull ((1))
>> ^
>> ./malloc/dynarray-skeleton.c:195:13: error: expected ')'
>> ./malloc/dynarray-skeleton.c:195:12: note: to match this '('
>> __nonnull ((1))
>> ^
>>
>> Complete build logs available at
>>
>> https://github.com/Homebrew/homebrew-core/pull/68667
>>
>> The errors (on 11.1) starts at
>>
>>
>> https://github.com/Homebrew/homebrew-core/pull/68667/checks?check_run_id=1674726970#step:7:910
>>
>> The exact same errors affect findutils 4.8.0, so the bug may not be in
>> wget. If so, I'd appreciate being pointed to the right place to submit
>> this bug report.
>
> I don't have a solution for you yet but just as another datapoint wget 1.21.1
> builds fine with those OS versions in MacPorts.
>
> If you want to compare your build logs with ours, for wget 1.21.1 ours are:
>
> https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/77011/steps/install-port/logs/stdio
>
> https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/48550/steps/install-port/logs/stdio
>
> https://build.macports.org/builders/ports-11_x86_64-builder/builds/15939/steps/install-port/logs/stdio
>
> In the process of trying to update the MacPorts findutils port from 4.7.0 to
> 4.8.0 just now, I encounter the same error that you see, on macOS 10.13. So
> there is something wrong there.
>
Re: Possible bug in configure script
On 1/25/21 1:25 PM, Peter Dyballa wrote: The configure script of wget 1.21.1 seems to have a bug, which becomes visible at least on old Mac OS X versions which use old GCC 4.2, see this report:https://trac.macports.org/ticket/62134. It's my assumption that the tests for C99 and C11 capabilities are incorrect while the maintainer assumes that it's a bug in gnulib I should report. Could you check whether we are both wrong? Or right? The topic has come up before: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg8.html but as far as I know nobody has tracked down what's causing the bug. I just now looked at the wget 1.21.1 tarball and it doesn't seem to contain anything Gnulib-relevant. In particular it does not contain a copy of gnulib/m4/std-gnu11.m4. So I don't see why the problem would be due to a bug in Gnulib. wget 1.21.1 was built with Autoconf 2.70, so the following post-2.70 patches to Autoconf might be relevant: https://git.savannah.gnu.org/cgit/autoconf.git/commit/?h=branch-2.70=efc940dc82763b7b2d6e65f04d15d5972d829c0a https://git.savannah.gnu.org/cgit/autoconf.git/commit/?h=branch-2.70=fac6e5e5cf5b974dda2b82d6331d9dcb4b3e0016
consult about make check
Dear Sir, After making without error message, I used the command "make check" to check. There are 6 items failed as follows. Is there any program on my pc (Red Hat Enterprise Linux Server release 6.2) absent? Best regards, Caihong Zhang FAIL: Test-hsts.py FAIL: Test--https.py FAIL: Test--https-crl.py PASS: Test-missing-scheme-retval.py PASS: Test-O.py FAIL: Test-pinnedpubkey-der-https.py FAIL: Test-pinnedpubkey-der-no-check-https.py FAIL: Test-pinnedpubkey-hash-https.py FAIL: Test-pinnedpubkey-hash-no-check-fail-https.py FAIL: Test-pinnedpubkey-pem-fail-https.py FAIL: Test-pinnedpubkey-pem-https.py PASS: Test-Post.py PASS: Test-recursive-basic.py PASS: Test-recursive-include.py PASS: Test-recursive-redirect.py PASS: Test-redirect.py PASS: Test-redirect-crash.py PASS: Test--rejected-log.py PASS: Test-reserved-chars.py PASS: Test--spider-r.py Testsuite summary for wget 1.20.3 # TOTAL: 44 # PASS: 35 # SKIP: 0 # XFAIL: 0 # FAIL: 9 # XPASS: 0 # ERROR: 0 bug-wget@gnu.org
--wait interrupted on SIGWINCH; nanosleep not used
Hello, I noticed that wget does interrupt its --wait between retrieval of multiple files when my terminal window gets resized. Reading through the sources it seems that the “xsleep” function (in utils.c) only supports the continuation of interrupted sleeps when the system provides a nanosleep function, which mine do, and the appropriate code is enabled when HAVE_NANOSLEEP is defined – but HAVE_NANOSLEEP does not appear to still get defined anywhere. Previously, it was AC_DEFINEd by a custom macro WGET_NANOSLEEP which was removed with [1] when instead Gnulib’s nanosleep module was added. The nanosleep module, though, only sets the shell variable HAVE_NANOSLEEP and AC_SUBST it (via time.h.m4): it does not define a macro for the C preprocessor. This means that nanosleep is not used anymore, anywhere, even on systems that would support it. >From here I am uncertain how to continue: - Has the fallback code to “usleep” and select become obsolete and should simply be removed from “xselect” as Gnulib takes care of the compatibility? (In this case the members of “struct timespec remaining”, probably, need to be initialised to 0 and checked before restarting nanosleep: the Gnulib’s fallback implementation does not appear to use or set it when interrupted.) - Should HAVE_NANOSLEEP be AC_DEFINEd again? - Maybe something else? So far, hopefully, I have analysed the issue correctly. [1] Commit: a384f5e2e9afd11e363d011b474c2e5da5573103 -- Felix Dietrich
Re: wget 1.21.1 fails to build on macOS (10.14, 10.15, 11.1)
On 25.01.21 06:40, Carlo Cabrera wrote:
> wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build
> fails with a series of errors starting with
>
> In file included from regex.c:74:
> In file included from ./regexec.c:1362:
> ./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
> __nonnull ((1))
> ^
> ./malloc/dynarray-skeleton.c:195:13: error: expected ')'
> ./malloc/dynarray-skeleton.c:195:12: note: to match this '('
> __nonnull ((1))
>^
>
> Complete build logs available at
>
> https://github.com/Homebrew/homebrew-core/pull/68667
>
> The errors (on 11.1) starts at
>
>
> https://github.com/Homebrew/homebrew-core/pull/68667/checks?check_run_id=1674726970#step:7:910
>
> The exact same errors affect findutils 4.8.0, so the bug may not be in
> wget. If so, I'd appreciate being pointed to the right place to submit
> this bug report.
>
>
This looks like a bug in the gnulib code. The correct place t o report
it would be bug-gnu...@gnu.org. I will try and take a closer look at it
soon, but I can't promise a timeline. A little too busy these days.
Re: wget 1.21.1 fails to build on macOS (10.14, 10.15, 11.1)
On Jan 24, 2021, at 23:40, Carlo Cabrera wrote:
> wget 1.21.1 fails to build on macOS 10.14, 10.15, and 11.1. The build
> fails with a series of errors starting with
>
>In file included from regex.c:74:
>In file included from ./regexec.c:1362:
>./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
>__nonnull ((1))
>^
>./malloc/dynarray-skeleton.c:195:13: error: expected ')'
>./malloc/dynarray-skeleton.c:195:12: note: to match this '('
>__nonnull ((1))
> ^
>
> Complete build logs available at
>
>https://github.com/Homebrew/homebrew-core/pull/68667
>
> The errors (on 11.1) starts at
>
>
> https://github.com/Homebrew/homebrew-core/pull/68667/checks?check_run_id=1674726970#step:7:910
>
> The exact same errors affect findutils 4.8.0, so the bug may not be in
> wget. If so, I'd appreciate being pointed to the right place to submit
> this bug report.
I don't have a solution for you yet but just as another datapoint wget 1.21.1
builds fine with those OS versions in MacPorts.
If you want to compare your build logs with ours, for wget 1.21.1 ours are:
https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/77011/steps/install-port/logs/stdio
https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/48550/steps/install-port/logs/stdio
https://build.macports.org/builders/ports-11_x86_64-builder/builds/15939/steps/install-port/logs/stdio
In the process of trying to update the MacPorts findutils port from 4.7.0 to
4.8.0 just now, I encounter the same error that you see, on macOS 10.13. So
there is something wrong there.
