SVR4 compile error
Compiling Wget 1.6 on an SVR4 derivative (NCR MP-RAS 3.0), I got
this strange error:
# make
CONFIG_FILES= CONFIG_HEADERS=src/config.h ./config.status
creating src/config.h
src/config.h is unchanged
generating po/POTFILES from ./po/POTFILES.in
creating po/Makefile
cd src make CC='cc -Xc -D__EXTENSIONS__' CPPFLAGS=''
DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\
-DLOCALEDIR=\/usr/local/share/locale\' CFLAGS='-O' LDFLAGS='' LIBS=''
prefix='/usr/local' exec_prefix='/usr/local' bindir='/usr/local/bin'
infodir='/usr/local/info' mandir='/usr/local/man' manext='1'
cc -Xc -D__EXTENSIONS__ -I. -I. -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\ -DLOCALEDIR=\/usr/local/share/locale\ -O
-c cmpt.c
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-98, NCR Corporation
(c) Copyright 1987-98, MetaWare Incorporated
cc -Xc -D__EXTENSIONS__ -I. -I. -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\ -DLOCALEDIR=\/usr/local/share/locale\ -O
-c connect.c
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-98, NCR Corporation
(c) Copyright 1987-98, MetaWare Incorporated
E /usr/include/arpa/inet.h,L66/C19(#164): in_addr_t
|Symbol declaration is inconsistent with a previous declaration
|at /usr/include/netinet/in.h,L47/C27.
E /usr/include/arpa/inet.h,L67/C19(#164): in_port_t
|Symbol declaration is inconsistent with a previous declaration
|at /usr/include/netinet/in.h,L46/C28.
E /usr/include/arpa/inet.h,L68/C1(#164): in_addr_t
|Symbol declaration is inconsistent with a previous declaration
|at /usr/include/netinet/in.h,L47/C27.
E /usr/include/arpa/inet.h,L69/C1(#164): in_port_t
|Symbol declaration is inconsistent with a previous declaration
|at /usr/include/netinet/in.h,L46/C28.
w (#657): (info) How referenced files were included:
|File /usr/include/netinet/in.h from connect.c.
|File /usr/include/arpa/inet.h from connect.c.
4 user errors 1 warning
*** Error code 4 (bu21)
make: fatal error.
*** Error code 1 (bu21)
make: fatal error.
I find it strange that there would be more than one definition
for in_addr_t and in_port_t. Does someone understand what's
going on and how to fix it ?
The output of configure:
# ./configure
creating cache ./config.cache
configuring for GNU Wget 1.6
checking host system type... i586-ncr-sysv4.3.03
checking whether make sets ${MAKE}... yes
checking for a BSD compatible install... ./install-sh -c
checking for gcc... no
checking for cc... cc
checking whether the C compiler (cc ) works... yes
checking whether the C compiler (cc ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cc accepts -g... no
checking how to run the C preprocessor... /lib/cpp
checking for AIX... no
checking for cc option to accept ANSI C... -Xc -D__EXTENSIONS__
checking for function prototypes... yes
checking for working const... yes
checking for size_t... yes
checking for pid_t... yes
checking whether byte ordering is bigendian... no
checking size of long... 4
checking size of long long... 8
checking for string.h... yes
checking for stdarg.h... yes
checking for unistd.h... yes
checking for sys/time.h... yes
checking for utime.h... yes
checking for sys/utime.h... yes
checking for sys/select.h... yes
checking for sys/utsname.h... yes
checking for pwd.h... yes
checking for signal.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking return type of signal handlers... void
checking for struct utimbuf... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for strdup... yes
checking for strstr... yes
checking for strcasecmp... no
checking for strncasecmp... no
checking for gettimeofday... yes
checking for mktime... yes
checking for strptime... yes
checking for strerror... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking for select... yes
checking for signal... yes
checking for symlink... yes
checking for access... yes
checking for isatty... yes
checking for uname... yes
checking for gethostname... no
checking for gethostbyname... no
checking for gethostbyname in -lnsl... no
checking for socket in -lsocket... no
checking whether NLS is requested... yes
language catalogs: cs da de el et fr gl hr it ja nl no pl pt_BR ru sk sl sv zh
checking for msgfmt... msgfmt
checking for xgettext... :
checking for gmsgfmt... msgfmt
checking for locale.h... yes
checking for libintl.h... no
checking for gettext... no
checking for gettext in -lintl... no
gettext not found; disabling NLS
checking for makeinfo... no
checking for emacs... no
checking for xemacs... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating
Re: SVR4 compile error
Andre Majorel [EMAIL PROTECTED] writes: Compiling Wget 1.6 on an SVR4 derivative (NCR MP-RAS 3.0), I got this strange error: I think the problem is that Wget 1.6 tried to force strict ANSI mode out of the compiler. Try running make like this: make CC=cc CFLAGS=-g See if it compiles then.
Hello~~!
Hello My name is March I'm a Chinese man First, I apology about my broken English. Second,I have a question about Wget as we know Wget can get the web file such as http://www.abc.com/index.html but I need to get the result of the program such as perl or php for expample http://google.yahoo.com/bin/query?p=wget can "wget" do it? or any other way can do it under FreeBSD? Thanks you Good day March
Re: -c option, again
Henrik van Ginhoven [EMAIL PROTECTED] writes: Neither english nor networking are my native languages, but with ``continued downloads'' I take it wget means ``continue on a file where you left off'', which in this case would be untrue, because sunet.se does support it. But Wget *thinks* that the server doesn't support it. Sending a debug log of (the relevant part of) the Wget run would probably help in determining what went wrong. Thanks for the report.
Re: -c option, again
On Sat, May 26, 2001 at 01:07:46PM +0200, Hrvoje Niksic wrote: But Wget *thinks* that the server doesn't support it. Sending a debug log of (the relevant part of) the Wget run would probably help in determining what went wrong. oops, forgot that (actually, I was afraid I had missed some new feature/changed behavior, so flooding the list with an unwanted debug log was something I wanted to avoid ;-) ) I believe the error is in that wget determine the server to not support -c without checking; because on a single file; $ src/wget -d -c -r -np http://ftp.sunet.se/pub/gnu/wget/wget-1.4.5.tar.gz /.../ ---request begin--- GET /pub/gnu/wget/wget-1.4.5.tar.gz HTTP/1.0 User-Agent: Wget/1.7-pre1 Host: ftp.sunet.se Accept: */* Connection: Keep-Alive Range: bytes=53040- ---request end--- HTTP request sent, awaiting response... HTTP/1.1 206 Partial Content Date: Sat, 26 May 2001 11:14:09 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Last-Modified: Fri, 09 May 1997 22:00:00 GMT ETag: 1c2a-3ed74-33739e60 Accept-Ranges: bytes Content-Length: 204356 Content-Range: bytes 53040-257395/257396 Connection: Keep-Alive Content-Type: application/x-tar Content-Encoding: x-gzip Found ftp.sunet.se in host_name_address_map: 194.71.11.20 Registered fd 3 for persistent reuse. Length: 257,396 (204,356 to go) [application/x-tar] [ skipping 50K ] 50K ,. .. .. .. /.../ it works just great as always, but using -c on the directory itself ... $ src/wget -d -c -r -np http://ftp.sunet.se/pub/gnu/wget/ /.../ ---request begin--- GET /pub/gnu/wget/ HTTP/1.0 User-Agent: Wget/1.7-pre1 Host: ftp.sunet.se Accept: */* Connection: Keep-Alive Range: bytes=4817- ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sat, 26 May 2001 11:27:50 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Connection: close Content-Type: text/html The server does not support continued downloads, which conflicts with -c'. /.../ -- Regards Henrik
Wget 1.7-pre1 available for testing
The pre-release of Wget is now available for testing. Please download it and see if it conforms to standards, expectations, if it compiles out of the box, etc. The pre-release is available at: ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.7-pre1.tar.gz If all goes well, I plan to release 1.7 some time next weekend. User-visible changes since 1.6 are: * Changes in Wget 1.7. ** SSL (`https') pages now work if you compile Wget with SSL support; use the `--with-ssl' configure flag. You need to have OpenSSL installed. ** Cookies are now supported. Wget will accept cookies sent by the server and return them in later requests. Additionally, it can load and save cookies to disk, in the same format that Netscape uses. ** Keep-alive (persistent) HTTP connections are now supported. Using keep-alive allows Wget to share one TCP/IP connection for many retrievals, making multiple-file downloads faster and less stressing for the server and the network. ** Wget now recognizes FTP directory listings generated by NT and VMS servers. ** It is now possible to recurse through FTP sites where logging in puts you in some directory other than '/'. ** You may now use `~' to mean home directory in `.wgetrc'. For example, `load_cookies = ~/.netscape/cookies.txt' works as you would expect. ** The HTML parser has been rewritten. The new one works more reliably, allows finer-grained control over which tags and attributes are detected, and has better support for some features like correctly skipping comments and declarations, decoding entities, etc. It is also more general. ** meta name=robots tags are now respected. ** Wget's internal tables now use hash tables instead of linked lists where appropriate. This results in huge speedups when retrieving large sites (thousands of documents). ** Wget now has a man page, automatically generated from the Texinfo documentation. (The last version that shipped with a man page was 1.4.5). To get this, you need to have pod2man from the Perl distribution installed on your system.
Re: -c option, again
Henrik van Ginhoven [EMAIL PROTECTED] writes: $ src/wget -d -c -r -np http://ftp.sunet.se/pub/gnu/wget/ I assume that ftp.sunet.se/pub/gnu/wget/index.html already exists at this point. /.../ ---request begin--- GET /pub/gnu/wget/ HTTP/1.0 User-Agent: Wget/1.7-pre1 Host: ftp.sunet.se Accept: */* Connection: Keep-Alive Range: bytes=4817- ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sat, 26 May 2001 11:27:50 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.3pl1 Connection: close Content-Type: text/html The server does not support continued downloads, which conflicts with -c'. /.../ But that's true, isn't it? The server didn't respond with a `Range' header, hence continued download doesn't work. Since you specified that the download should be continued, Wget refuses to truncate up your file by starting the download anew.
Re: -c option, again
The server does not support continued downloads, which conflicts with -c'. But that's true, isn't it? The server didn't respond with a `Range' header, hence continued download doesn't work. Since you specified that the download should be continued, Wget refuses to truncate up your file by starting the download anew. Aah.. Yes, you are right as always. However, once wget determine the (index.html) file to be completely downloaded, shouldn't it start going through the file for links instead of quiting? I believe that was the 'old' behavior I was looking for. Also, (not trying to save my face here ;-) - but The server does not support continued downloads might not be the best phrase to use, since it gives the impression that the server _never_ supports continued downloads.. well just a thought. -- Regards Henrik
Re: Wget 1.7-pre1 available for testing
On Sat, May 26, 2001 at 01:35:40PM +0200, Hrvoje Niksic wrote: The pre-release of Wget is now available for testing. Please download it and see if it conforms to standards, expectations, if it compiles out of the box, etc. The pre-release is available at: ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.7-pre1.tar.gz Seems to compile OK on OS/2 straight out of the box - which is excellent! I'd like to see an additional entry in MACHINES acknowledging this... IBM OS/2 (i[3456]86) -- John
Re: -c option, again
Henrik van Ginhoven [EMAIL PROTECTED] writes: On Sat, May 26, 2001 at 01:56:41PM +0200, Hrvoje Niksic wrote: Sp00l [EMAIL PROTECTED] (d'uh, damn mail) writes: Aah.. Yes, you are right as always. However, once wget determine the (index.html) file to be completely downloaded, shouldn't it start going through the file for links instead of quiting? Doesn't it do that? If not, it's a bug. hm, I guess you're right.. no it doesn't, it just finish after the 'The server does not support continued downloads'. Ah, I see. But I guess it did not really determined that the download was in fact complete. If the server refuses to do `Range', how can it know whether the file is complete or not? But you did force continued download with `-c', so that's what gets precedence. If this is what you want, you should probably use `-nc' (no-clobber == treat existing files as already downloaded) rather than `-c' (continue). Or maybe there should be a way to specify that the old it-is-OK-to-start-from-scratch-if-continued-download-fails behaviour is desired. You're right. Maybe the message should be continued download failed with this file or something like that? I'd vote for that ;-) Done. The message is now: Continued download failed on this file, which conflicts with `-c'. Refusing to truncate existing file `%s'.
