Re: [Bug-wget] progressive download feature request
On Dec 27, 2011, at 4:36 PM, Keisial wrote: On 27/12/11 17:05, Michal Tausk wrote: The --ignore-length is not taken into consideration, (logically) when using --continue as it needs to count the difference in size between the downloaded file and the remote file. However, the file is downloaded only up to the content-length it retrieved on the last invocation of wget -c. It doesn't need to use Content-Length with -c, and in fact -c doesn't seem to inhibit ignore-length, so it should work. Are you sure it's not the server sending you only up to the length that was available when you requested the file? If you can put wireshark on it, check to see which FIN comes over first. I bet Keisial is right. I bet the server is telling wget I'm done by sending the FIN. Hope this helps pedz
Re: [Bug-wget] getopt/'struct options' build error in 1.13.1
I thought you were just going to remove the include of wget.h ? On Aug 17, 2011, at 9:09 AM, Giuseppe Scrivano wrote: ops... Thanks to have reported it. I am sure it depends from a fix for a similar error Perry had on AIX. At this point, it seems the only way to fix the problem is to include config.h at the very beginning of css.c. I have looked at the flex documentation but I can't find anything useful to prevent other files to be included before the C code snippet. Has anybody an idea? Should I go for an hack? Cheers, Giuseppe Jack Nagel jackna...@gmail.com writes: I have encountered an issue building wget 1.13.1 on Mac OS X 10.6.8. It fails during 'make' with gcc 4.2 here: /usr/bin/cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\ -DLOCALEDIR=\/usr/local/share/locale\ -I. -I../lib -I../lib -c css.c In file included from ../lib/unistd.h:113:0, from css.c:4738: ../lib/getopt.h:196:8: error: redefinition of 'struct option' /usr/include/getopt.h:54:8: note: originally defined here ../lib/getopt.h:245:12: error: conflicting types for 'getopt_long' /usr/include/getopt.h:69:5: note: previous declaration of 'getopt_long' was here ../lib/getopt.h:249:12: error: conflicting types for 'getopt_long_only' /usr/include/getopt.h:71:5: note: previous declaration of 'getopt_long_only' was here However, I can successfully build wget 1.13 on the same system under the same conditions. (Please CC as I am not subscribed to the list). Thanks in advance for the help. Jack
Re: [Bug-wget] getopt/'struct options' build error in 1.13.1
On Aug 17, 2011, at 6:20 PM, Jack Nagel wrote: On Wed, Aug 17, 2011 at 2:52 PM, Giuseppe Scrivano gscriv...@gnu.org wrote: to facilitate the testing, I have uploaded a tarball here: http://it.gnu.org/~gscrivano/files/wget-1.13.1-dirty.tar.bz2 I have the same build error with this version. Bummer... this version is working for me on AIX 6.1 I built it without-ssl and also with-ssl=openssl pedz
Re: [Bug-wget] [wget 1.13] [configure error] Forcing to use GnuTLS? --with-ssl was given, but GNUTLS is not available
On Aug 13, 2011, at 12:34 PM, Douglas Mencken wrote: If you want to use OpenSSL then you have to pass --with-ssl=openssl. I hope this would be mentioned in README and/or INSTALL. And that configure.ac will be fixed to say something better than stupid --with-ssl was given, but GNUTLS is not available (especially, when --with-ssl hasn't been explicitly given at all — this do really confuses people). I suppose, plain ./configure would give me the same error too. I took a stab at installing GNUTLS and gave up. The beauty of wget is I can get it going with very few things needed. I compiled without ssl at all but getting openssl going is fairly easy too. GNUTLS is asking for nettle, zlib, and something else (according to the web page) but then it snuck up and started asking for pkg-config. That is way down the list in my bring up sequence. I guess... I don't get what is wrong with openssl. Why do we need GNUTLS at all? (we being the open source community.) pedz
Re: [Bug-wget] wget-1.13 on AIX
Hi, On my 6.1 system I do not have flex so I removed the include from css.c and it compiled. On my 5.3 system I do have flex. Removing it from css.l worked as well. I am configuring --without-ssl but I'm assuming that will not make a difference for this. Thanks, Perry On Aug 12, 2011, at 10:20 AM, Giuseppe Scrivano wrote: Hello Perry, thanks to have reported it. Does it work correctly if you drop the #include wget.h line from css.l? === modified file 'src/css.l' --- src/css.l 2011-01-01 12:19:37 + +++ src/css.l 2011-08-12 15:18:23 + @@ -36,7 +36,6 @@ #define YY_NO_INPUT -#include wget.h #include css-tokens.h %} Thanks, Giuseppe Perry Smith pedz...@gmail.com writes: Hi, I've tried this on AIX 5.3 and 6.1. The problem is with src/css.c. In essence it is doing this: #include stdio.h #include string.h #include errno.h #include stdlib.h #include inttypes.h #define _LARGE_FILES #include unistd.h The #define of _LARGE_FILES is actually done in config.h via wget.h. I understand that AIX is very hard to deal with but this seems like a bad idea for any platform. If you are going to declare that you want _LARGE_FILE support, you need to do that before any system includes. What this causes is both _LARGE_FILES and _LARGE_FILE_API both get defined and that causes one place to declare (for example) #define ftruncate ftruncate64 (this is in unistd.h around line 733) and then later we have: extern int ftruncate(int, off_t); #ifdef _LARGE_FILE_API extern int ftruncate64(int, off64_t); #endif (around line 799) which the compiler complains about with: /usr/include/unistd.h:801: error: conflicting types for 'ftruncate64' /usr/include/unistd.h:799: error: previous declaration of 'ftruncate64' was here There are actually several pairs of these. With the above code snippet, if you move the #define to the top, (or completely remove it) the compile works fine. It just seems like it would be prudent to declare things like _LARGE_FILES in config.h (like you do) but put config.h as the first include of each file so that the entire code base knows which interface the program wants to use. What I did was to move css.c to _css.c. I put an #ifndef _CONFIG_H wrapper inside config.h and then the new css.c was simply: #include config.h #include _css.c and that worked for my 5.3 system. I have not tried it on my 6.1 system yet. I hope this helps someone. Thank you, pedz
[Bug-wget] wget-1.13 on AIX
Hi, I've tried this on AIX 5.3 and 6.1. The problem is with src/css.c. In essence it is doing this: #include stdio.h #include string.h #include errno.h #include stdlib.h #include inttypes.h #define _LARGE_FILES #include unistd.h The #define of _LARGE_FILES is actually done in config.h via wget.h. I understand that AIX is very hard to deal with but this seems like a bad idea for any platform. If you are going to declare that you want _LARGE_FILE support, you need to do that before any system includes. What this causes is both _LARGE_FILES and _LARGE_FILE_API both get defined and that causes one place to declare (for example) #define ftruncate ftruncate64 (this is in unistd.h around line 733) and then later we have: extern int ftruncate(int, off_t); #ifdef _LARGE_FILE_API extern int ftruncate64(int, off64_t); #endif (around line 799) which the compiler complains about with: /usr/include/unistd.h:801: error: conflicting types for 'ftruncate64' /usr/include/unistd.h:799: error: previous declaration of 'ftruncate64' was here There are actually several pairs of these. With the above code snippet, if you move the #define to the top, (or completely remove it) the compile works fine. It just seems like it would be prudent to declare things like _LARGE_FILES in config.h (like you do) but put config.h as the first include of each file so that the entire code base knows which interface the program wants to use. What I did was to move css.c to _css.c. I put an #ifndef _CONFIG_H wrapper inside config.h and then the new css.c was simply: #include config.h #include _css.c and that worked for my 5.3 system. I have not tried it on my 6.1 system yet. I hope this helps someone. Thank you, pedz
[Bug-wget] Build problem on AIX for wget-1.12
On a system that does not have getopt.h in its /usr/include, the build will stop when src/main.c is compiled for an out of tree build. The list of -I options does not include one for ../lib which is where getopt.h is found. I worked around it by just editing src/Makefile and adding in some -I paths. Hope this helps, Perry Smith
[Bug-wget] Build problem on AIX for wget-1.12
On a system that does not have getopt.h in its /usr/include, the build will stop when src/main.c is compiled for an out of tree build. The list of -I options does not include one for ../lib which is where getopt.h is found. I worked around it by just editing src/Makefile and adding in some -I paths. Hope this helps, Perry Smith
