Re: [Bug-wget] alpha release (1.13.4.56-620c)
>It's not really your fault, but the GNU regex code (lib/regcomp.c) > has an annoying portability problem, [...] The gnulib folks have fixed this regcomp.c problem. I don't much like the solution they adopted, but it does get past more compilers than the old code. http://lists.gnu.org/archive/html/bug-gnulib/2012-05/msg00276.html Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: [Bug-wget] alpha release (1.13.4.56-620c)
From: Giuseppe Scrivano > > http://lists.gnu.org/archive/html/bug-wget/2012-05/msg00086.html > > > > Or is something else needed? > > is that enough to solve the problem? It's enough to solve _that_ problem. > I am going to include this patch and then prepare a new alpha release. > There are no blocking issues and I would like to get a new release as > soon as possible. I gather that the unsigned-size_t problem in "src/warc.c" has been solved, but, so far as I know, the other problems mentioned there may remain (_SOCKADDR_LEN on Tru64, "%ld" for an off_t in "src/warc.c"). > [...] I did see some "xxx_T_SUFFIX" macros, but not one for this case. Of course, as I noticed after I wrote that, the "xxx_T_SUFFIX" macros are "UL"-like things, used for forming constants, not "%ld"-like things, for use in format strings. And, as always, thanks for the help. Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: [Bug-wget] alpha release (1.13.4.56-620c)
"Steven M. Schweda" writes: >Do you mean like this?: > > [...] > ALP $ gdiff -du src/connect.c_orig src/connect.c > [...] > > http://lists.gnu.org/archive/html/bug-wget/2012-05/msg00086.html > > Or is something else needed? is that enough to solve the problem? I am going to include this patch and then prepare a new alpha release. There are no blocking issues and I would like to get a new release as soon as possible. Cheers, Giuseppe
Re: [Bug-wget] alpha release (1.13.4.56-620c)
From: Giuseppe Scrivano > By using gnulib we can assume these headers _always_ exist. In case the > system doesn't provide them, then gnulib will offer a replacement. > > The problem here is that you can't use "configure", right? Yes. In general: no shell, no compatible utilities, ..., no hope. > if that is the problem, you can submit a patch which re-introduces these > macros. It might not be elegant, but if it solves this problem then > there are no problems to leave them there, for systems using "configure" > they are just a no-op. Do you mean like this?: [...] ALP $ gdiff -du src/connect.c_orig src/connect.c [...] http://lists.gnu.org/archive/html/bug-wget/2012-05/msg00086.html Or is something else needed? > Providing such a patch helps more than complaining about portability of > GNU programs, I think. Complaining is very enjoyable, though. Of course, it's more enjoyable when it's effective (as it generally is here). Apparently, complaining about the fundamental GNU regex problem gets one advice like "get the compiler fixed": http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00154.html Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: [Bug-wget] alpha release (1.13.4.56-620c)
Ángel González writes: > On 22/05/12 22:49, Steven M. Schweda wrote: >>There's a new problem on systems (like VMS) where size_t is unsigned: > getline() returns a ssize_t, there's a bug in defining line_length as size_t > > Giuseppe, can you add the missing 's'? (src/warc.c line 933) Done and pushed the patch! Giuseppe
Re: [Bug-wget] alpha release (1.13.4.56-620c)
"Steven M. Schweda" writes: >Obviously not, or we wouldn't be having this discussion. For Wget > 1.13.4 on VMS, I added these modifications to src/connect.c, because, as > I recall, the argument that HAVE_SYS_SOCKET existed for some reason was > unsuccessful. I never understood why, so I thought that I'd take > another run at it this time. Perhaps my mind is simply too weak for > this stuff, but I can't help thinking that if the #define directives for > HAVE_SYS_SELECT_H and HAVE_SYS_SOCKET_H in the generated src/config.h > are correct, then actually using these macros to guard the relevant > #include directives should be harmless, at worst. But what do I know? if that is the problem, you can submit a patch which re-introduces these macros. It might not be elegant, but if it solves this problem then there are no problems to leave them there, for systems using "configure" they are just a no-op. Providing such a patch helps more than complaining about portability of GNU programs, I think. Giuseppe
Re: [Bug-wget] alpha release (1.13.4.56-620c)
Ray Satiro writes: > Do you have in your wget gnulib dir lib\sys\ those includes? I was under the > impression those were used. > This goes back to > http://lists.gnu.org/archive/html/bug-wget/2012-03/msg00082.html > > If you're going to use those then AC_CHECK_HEADERS or something needs to > check for the gnulib includes. I think there was some problem with that. I > can't find it in the thread but if I remember right rather than add to the > check Giuseppe removed the HAVEs because they are always required.. aren't > they? By using gnulib we can assume these headers _always_ exist. In case the system doesn't provide them, then gnulib will offer a replacement. The problem here is that you can't use "configure", right? Giuseppe
Re: [Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)
>It's not really your fault, but the GNU regex code (lib/regcomp.c)
> has an annoying portability problem, because what could easily have been
> a compile-time decision was postponed until run-time. A good compiler
> complains about loss of significant bits when BITSET_WORD_BITS < 64:
>
> if (BITSET_WORD_BITS == 64)
> {
> dfa->word_char[0] = UINT64_C (0x03ff);
> dfa->word_char[1] = UINT64_C (0x07fe87fe);
>
> Not fatal, however, only annoying. (And, I claim, stupid. And
> relatively easy to fix, unless you _really_ like it the way it is, which
> seems to be the case for the GNU regex maintainer.)
Actually, on VAX (where a 64-bit integer type in unavailable), it's
fatal:
CC /decc /include = ([], [.VAX], [-.SRC.VAX], [-.VMS]) /prefix_library_entri
es = (all_entries, except = (getopt, optarg, opterr, optind, optopt))/objec
t = [.VAX]REGEX.OBJ /define = (VMS, _POSIX_EXIT, OS_TYPE="""VMS VAX V7.3""" , -
"ENABLE_DEBUG" , "HAVE_LIBSSL", "ENABLE_NTLM" ) [-.LIB]REGEX.C
dfa->word_char[0] = UINT64_C (0x03ff);
..^
%CC-E-INTCONST, Ill-formed integer constant.
At line number 963 in SYS$SYSDEVICE:[UTILITY.SOURCE.WGET.WGET-1_
13_4_56-620C.LIB]REGCOMP.C;1.
dfa->word_char[1] = UINT64_C (0x07fe87fe);
..^
%CC-E-INTCONST, Ill-formed integer constant.
At line number 964 in SYS$SYSDEVICE:[UTILITY.SOURCE.WGET.WGET-1_
13_4_56-620C.LIB]REGCOMP.C;1.
>I assume that I'll find more problems as I try to get the new code
> into the VMS builders, but those are the ones which popped up first.
I'm such a pessimist. Actually, with a little adjustment to the
VMS-specific files, building on Alpha (and, I assume, on IA64 -- What
could go wrong?) seems to be ok. Even more amazingly, I seem to have
found a truly stupid-looking work-around for that
should-have-been-compile-time conditionality problem in the GNU regex
code on VAX:
# ifdef __VAX
# define UINT64_C(c) 0
Apparently, at least in some cases, one piece of truly stupid code can
cancel out another.
HAVE_FSEEKO and HAVE_FTELLO (also unavailable on VAX) seem to get
about as much respect as HAVE_SYS_SELECT_H and HAVE_SYS_SOCKET_H, but I
should be able to deal with that, too.
I haven't done any serious testing (just fetched a Web page on
Alpha), but, except for the problems previously reported, builds on VMS
should be possible.
Steven M. Schweda sms@antinode-info
382 South Warwick Street(+1) 651-699-9818
Saint Paul MN 55105-2547
Re: [Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)
On 22/05/12 22:49, Steven M. Schweda wrote: >There's a new problem on systems (like VMS) where size_t is unsigned: getline() returns a ssize_t, there's a bug in defining line_length as size_t Giuseppe, can you add the missing 's'? (src/warc.c line 933)
Re: [Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)
From: Ray Satiro > [...] your wget gnulib dir [...] You may be confusing "GNU" with "portable". They're not even similar. All the GNU-autojunk in the world does me approximately no good at all. sys_select.in.h, sys_socket.in.h, and the like, are useful only if someone can turn them into actual header files, and on VMS, I, not some GNU-autojunk, am the one who would need to do it. And, as I said, I don't even have a convenient way to use a "sys" directory (without wrecking access to existing stuff). > [...] they are always required.. aren't they? Obviously not, or we wouldn't be having this discussion. For Wget 1.13.4 on VMS, I added these modifications to src/connect.c, because, as I recall, the argument that HAVE_SYS_SOCKET existed for some reason was unsuccessful. I never understood why, so I thought that I'd take another run at it this time. Perhaps my mind is simply too weak for this stuff, but I can't help thinking that if the #define directives for HAVE_SYS_SELECT_H and HAVE_SYS_SOCKET_H in the generated src/config.h are correct, then actually using these macros to guard the relevant #include directives should be harmless, at worst. But what do I know? Steven M. Schweda sms@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: [Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)
> From: Steven M. Schweda > This problem on VMS is still unsolved: > > ALP $ gdiff -du src/connect.c_orig src/connect.c > --- src/connect.c_orig 2012-05-12 10:18:27 -0500 > +++ src/connect.c 2012-05-22 07:59:19 -0500 > @@ -36,8 +36,13 @@ > #include > #include > > -#include > -#include > +#ifdef HAVE_SYS_SOCKET_H > +# include > +#endif /* def HAVE_SYS_SOCKET_H */ > + > +#ifdef HAVE_SYS_SELECT_H > +# include > +#endif /* def HAVE_SYS_SELECT_H */ > > #ifndef WINDOWS > # ifdef __VMS > > I don't have anything like , and adding a dummy > replacement would be annoying, because I also don't have a "sys" > directory. What's the point of defining the macros HAVE_SYS_SELECT_H > and HAVE_SYS_SOCKET_H in src/config.h, and then not using them where > appropriate? (When asked for , the DEC/Compaq/HP compiler > will look for in its usual places, so "#include > " > actually works (using ), but this will fail if I create a new > "sys" directory for . There may be some complex > and ugly > work-around for this, bit it's simpler and cleaner to use the existing > macros. Which is why they exist, isn't it?) > > Do you have in your wget gnulib dir lib\sys\ those includes? I was under the impression those were used. This goes back to http://lists.gnu.org/archive/html/bug-wget/2012-03/msg00082.html If you're going to use those then AC_CHECK_HEADERS or something needs to check for the gnulib includes. I think there was some problem with that. I can't find it in the thread but if I remember right rather than add to the check Giuseppe removed the HAVEs because they are always required.. aren't they?
Re: [Bug-wget] alpha release (1.13.4.56-620c) (was: [PATCH] gnutls.c: fix infinite read timeout)
Hi Guiseppe, Am 21.05.2012 um 23:23 schrieb Giuseppe Scrivano: > Giuseppe Scrivano writes: > >> thanks again for your contribution! The patch seems ok to me. Could >> you please also provide a complete entry for the ChangeLog file? > > I have amended the ChangeLog entry in your patch and pushed it. I think > this is the last big change before the new release. > > I have prepared an alpha release here: > > ftp://alpha.gnu.org/gnu/wget/wget-1.13.4.56-620c.tar.bz2 > ftp://alpha.gnu.org/gnu/wget/wget-1.13.4.56-620c.tar.bz2.sig > > Please test it and let me know of any problem. Testsuite passes fully on Solaris 9 Sparc with Sun Studio 12. BTW, it would be nice if the CA path in src/gnutls.c would be configurable, but this just as a side note :-) Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896
