Wget source is available at http://www.gnu.org/software/wget/
February 23, 2015
Updated downloads moved to main page
October 29, 2014
wget-1.16 (with openssl 1.0.1i, pdf manual, wget.ini sample, locales and ca certificate)
Use 7zip/WinRAR to extract the archive
January 22, 2014
wget-1.15 (with openssl 1.0.1f, pdf manual, wget.ini sample, locales and ca certificate)
August 11, 2012
wget-1.14 (openssl 1.0.1c) optional files (locales, ca-bundle)
February 1, 2012
wget-1.13.4 (openssl 1.0.0g) locales ca-bundle-crt (expired 2018) [patch]
- wget should lookup wget.ini and locales relative to where wget.exe located not from current directory
- by default search for curl-ca-bundle.crt for secure protocol when ca-certificate-file not defined
December 7, 2011
- fixed gnulib stat() that return invalid filesize >2GB (patched mswindows.h)
- use wget.ini in current directory for default wgetrc
- apply apache's dirlist patch
September 6, 2011
wget-1.13.1.exe
- timestamp fix and apache dirlist patch
How to build?
Someone asked, but honestly I don't find anything intricate about building it with MinGW.. the one that hard is version 1.12.x where I need to modify some win32api's header to enable IPv6, apply some minor patch and manually "make" for the final linking. Version 1.13.x however is just simply configure and make, that's it. Of course assuming you already had all dependencies (libidn, libintl, winiconv, openssl), one caveat is libidn as user commented below, it maybe just me (i'm not sure) but I need to rebuild winiconv and later libidn to make it "see" the statically linked iconv.
March 30 2011
I made alternative build based on this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217243 to workaround those annoying apache auto-generated directory listings.
As you can see, we still can't get rid of index.html, but it's way much faster for handling hundreds of directories! enjoy! :)
May 14 2010
It seems my previous mingw built didn't support IPv6 :D
That's really strange.. AFAIK ws2tcpip.h does support IPv6. I decide to fool configure to enable it. And I've done it. The new binary now support IPv6 and IRI. Same link as above.
Can you compile release 1.13 of wget?
ReplyDeleteDude, don't use url as name! otherwise your comment went to spam..
ReplyDeleteHere you go (untested)
http://dl.dropbox.com/u/2554170/wget-1.13.1.exe
with apache dirlist patch
Enjoy
Thank you very much TumaGonx Zakkum. I've been trying wget 1.12 (for Windows) from lots of webs, and all of these (included yours) have the same problem: when I add an input file with a full path like this: -i d:\mydir\links.txt I get the error: No URLs found.
ReplyDeleteBut your 1.13.1 version works perfectly. THANKS.
Inframan
I've just discovered that the 1.13.1 version has a minor problem: it doesn't retrive the original files' time stamps. It was the default behaviour of my former 1.11.4.
ReplyDeleteInframan
your first problems, you should use relative path for your input list not absolute, but I always prefer wgetrc way (in this case use set wgetrc=[absolute path to wgetrc]
ReplyDeletefor timestamp, it works just fine again I recommend use thw wgetrc way man, it goes like this:
background = on
input = config/down.txt
logfile = log.txt
convert_links = on
no_parent = on
noclobber = off
continue = on
recursive = on
adjust_extension = on
verbose = on
quota = inf
tries = 30
reclevel = inf
passive_ftp = on
waitretry = 10
restrict-file-names = windows
timestamping = on
wait = 1
dirstruct = on
follow_ftp = on
limit_rate = 8k
dir_prefix = D:\Leech\downloads
#http_proxy = http://127.0.0.1:8080
tumagonx
then check your logs to see why stamping doesn't work, I believe it was server-side issue
ReplyDeleteI used the wgetrc with your options (especially timestamping = on), but it keeps failing. Every file is saved with the current time, not the original. And yes, on some ocassions it's a server-side issue, but not always. The only error I saw in my log was:
ReplyDeletefutimens(D:/downloaded file in my hdd): Function not implemented
About the full path, sometimes I have the file in a USB drive, so it's needed to write the full path (including the letter for drive) to make it works.
Thanks for your quick answer and help
Inframan
hmm, those futimens error usually special file like robot.txt
ReplyDeletemy usual error is "Last-modified header missing" for all autogenerated files.
Well, glad 1.13.1 fix that input list path... My way is to put wget.exe, wgetrc, wget.bat and the listfile in a folder so even in flashdisk that doesn't really matter.
after see the source, futimens is newly introduced in 1.13 but seems implemented for linux only and you're right it handle time-modification of file
ReplyDeleteI revert timestamping to previous version (before using futimens), it works now. And it seems has no side effect as it only used in utils.c. Thanks alot for the report man.
ReplyDeleteenjoy
Now that it's fixed the timestamping, I can use this version on a daily basis instead of the dated 1.11.4 from http://users.ugent.be/~bpuype/wget/. If something's going wrong, I'll make you know. Thanks to you for compiling, fixing and sharing with the community.
ReplyDeleteInframan
When I run it on Windows 7 I get an error about libidn:
ReplyDeleteC:\bin>wget-1.13.1.exe -6 www.savvis.com
--2011-09-05 21:32:17-- http://www.savvis.com/
libidn: warning: libiconv not installed, cannot convert data to UTF-8
Resolving www.savvis.com (www.savvis.com)... 2001:460:100:1000::37
libidn: warning: libiconv not installed, cannot convert data to UTF-8
Connecting to www.savvis.com (www.savvis.com)|2001:460:100:1000::37|:80... failed: Bad file descriptor.
C:\bin>
What's the issue?
The previous libidn apparently not linked to correct libiconv (I use winiconv). Updated, thanks for your report Frank
ReplyDeleteCould you please build wget 1.13.4?
ReplyDeletehttp://dl.dropbox.com/u/2554170/wget-1.13.4/wget.exe (untested)
ReplyDeleteCan you give us a guide for compile wget 1.13.4?I have tried, but failed, the wget which I compiled cannot support openssl, and need libidn-11.dll
ReplyDeleteThanks!
ReplyDeletewget executable without any external dependencies and DLL is so cool and convenient.
Hi,
ReplyDeleteperfect job! Could you try build 64bit version too? Thanks a lot
Why?
ReplyDeleteHello. Big file download error.
ReplyDelete1.11.4 works fine
Thank You
M:\DELL>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
--2011-12-02 15:07:41-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving ftp.dell.com (ftp.dell.com)... 143.166.170.10, 143.166.170.10
Connecting to ftp.dell.com (ftp.dell.com)|143.166.170.10|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /sysman ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> PASV ... done. ==> REST -2030076516 ...
REST failed, starting from scratch.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G) (unauthoritative)
0% [ ] 0 --.-K/s in 0,2s
sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
Sorry can't reproduce that, works for me:
ReplyDeleteE:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c ftp://ftp.dell.com/sysm
an/sm_6.5.0-15_A00.2.iso
--2011-12-02 19:15:55-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving ftp.dell.com (ftp.dell.com)... 143.166.170.10
Connecting to ftp.dell.com (ftp.dell.com)|143.166.170.10|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /sysman ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> PASV ... done. ==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2.7G) (unauthoritative)
0% [ ] 62,560 2.56K/s eta 11d 18h
File was downloaded for about 2.1 GB before error occures
ReplyDeleteResuming after replacing 1.13.4 with 1.11.4
ReplyDeleteM:\DELL>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = c:/progra~1/wget/etc/wgetrc
--2011-12-02 15:09:09-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving ftp.dell.com... 143.166.170.10, 143.166.170.10
Connecting to ftp.dell.com|143.166.170.10|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /sysman ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> PASV ... done. ==> REST 2264890780 ... done.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G), 623880804 (595M) remaining
100%[++++++++++++++++++++++++++++++++++++++++++++============>] 2 888 771 584 308K/s in 36m 14s
2011-12-02 15:45:27 (280 KB/s) - `sm_6.5.0-15_A00.2.iso' saved [2888771584]
Your first error definitely different from your last. Please don't hide the real error?
ReplyDeleteAnd 2.1 Gb is pass the "large file" barrier already. So I don't have to prove it on my slow 128kpbs connection here
I got an idea to simulate this, I wrote dummy file about 2.84gb and hook it to Scientific Linux ISO download. No problemo
ReplyDeleteE:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c ftp://ftp1.scientificli
nux.org/linux/scientific/6.1/x86_64/iso/SL-61-x86_64-2011-11-09-Everything-DVD1.
iso
--2011-12-02 23:00:06-- ftp://ftp1.scientificlinux.org/linux/scientific/6.1/x86
_64/iso/SL-61-x86_64-2011-11-09-Everything-DVD1.iso
=> `SL-61-x86_64-2011-11-09-Everything-DVD1.iso'
Resolving ftp1.scientificlinux.org (ftp1.scientificlinux.org)... 131.225.110.41
Connecting to ftp1.scientificlinux.org (ftp1.scientificlinux.org)|131.225.110.41
|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /linux/scientific/6.1/x86_64/iso ... done.
==> SIZE SL-61-x86_64-2011-11-09-Everything-DVD1.iso ... 4492019712
==> PASV ... done. ==> REST -1237838128 ... done.
==> RETR SL-61-x86_64-2011-11-09-Everything-DVD1.iso ... done.
Length: 4492019712 (4.2G) (unauthoritative)
-27%[ ] -1,237,711,648 3.78K/s eta 22d 22h
Hello.
ReplyDeleteMy way to reproduce error.
File was truncated at point 2264890780 bytes, point, where download was interrupted when downloading from ftp.dell.com.
Trying to continue download from dell
M:\temp>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
--2011-12-05 08:44:17-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving ftp.dell.com (ftp.dell.com)... 143.166.11.10, 143.166.11.10
Connecting to ftp.dell.com (ftp.dell.com)|143.166.11.10|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /sysman ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> PASV ... done. ==> REST -2030076516 ...
REST failed, starting from scratch.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G) (unauthoritative)
0K 0% 0,00 =0,2s
sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
now trying to download from local ftp site
M:\temp>wget -c ftp://username:password@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
--2011-12-05 08:44:42-- ftp://username:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:21... connected.
Logging in as dstrr ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> EPSV ... done. ==> REST -2030076516 ...
REST failed, starting from scratch.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G) (unauthoritative)
0K 0% 0,00 =0,03s
sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
content of working directory
Directory of M:\temp
05.12.2011 08:43 2 264 890 780 sm_6.5.0-15_A00.2.iso
1 File(s) 2 264 890 780 bytes
2 Dir(s) 582 830 100 480 bytes free
Download of complete file without break and continue works well. May be point of REST calculates incorrectly? wget 1.11.4 makes REST without negative sign ant at different point.
now i replaced wget.exe with 1.11.4
M:\temp>wget -c ftp://username:password@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = c:/progra~1/wget/etc/wgetrc
wgetrc_file_name = c:\Windows\wgetrc
--2011-12-05 09:04:49-- ftp://username:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|127.0.0.1|:21... connected.
Logging in as dstrr ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /mdrive/dell ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> PASV ... done. ==> REST 2264890780 ... done.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G), 623880804 (595M) remaining
100%[++++++++++++++++++++++++++++++++++++++++++++============>] 2 888 771 584 29,9M/s in 14s
2011-12-05 09:05:03 (43,6 MB/s) - `sm_6.5.0-15_A00.2.iso' saved [2888771584]
Thank You.
Hello.
ReplyDeleteChronologically:
1. wget 1.13.4 started download from dell and download was broken at point 2264890780. i maked wget -c and result was shown in the first post. i tried for a 3-5 times.
2. wget.exe 1.13.4 was replaced with 1.11.4 and issued the same command - download was resumed and completed successfully. This shown in the second post.
I can reproduce this behavior. i have complete file, and make partial copy with end at point 2264890780 and resuming download. i'm using dell ftp and local ftp, behavior the same, error is in place.
Thank You.
A hour ago i made big post with screenshots, but it disappeared.
can you display what's the invalid argument? by reading the logfile like when I ask inframan in early posts
ReplyDeletethe REST is negative but so does the progress percentage. See my comment before
ReplyDeleteE:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c -d ftp://ftp.dell.com/s
ReplyDeleteysman/sm_6.5.0-15_A00.2.iso
DEBUG output created by Wget 1.13.4 on mingw32.
URI encoding = `ASCII'
--2011-12-05 14:55:25-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving ftp.dell.com (ftp.dell.com)... seconds 0.00, 143.166.11.10
Caching ftp.dell.com => 143.166.11.10
Connecting to ftp.dell.com (ftp.dell.com)|143.166.11.10|:21... seconds 0.00, con
nected.
Created socket 3.
Releasing 0x00ab6d60 (new refcount 1).
Logging in as anonymous ... 220 Microsoft FTP Service
--> USER anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
--> PASS -wget@
230-Welcome to the Dell FTP site. A service of Dell Inc., Round Rock, Texas.
For information about DELL, call +1 800 999 3355 All transfers are logged wi
th
your host name and email address. If you don't like this policy please disco
nnect now.
Please be advised that use constitutes consent to monitoring (Elec Comm Priv
Act,
18 USC 2701-2711). Please see the file readme.txt for disclaimers pertaining
to this
service. If your FTP client crashes or hangs shortly after login, try using
a dash
(-) as the first character of your password. This will turn off the informat
ional
messages which may be confusing your ftp client.
********IN CASE OF PROBLEMS*************************
** File Content: send EMAIL to dellbbs@dell.com **
** FTP Server: send EMAIL to hostmaster@dell.com **
** WWW Server: send EMAIL to webmaster@dell.com **
****************************************************
230 User logged in.
Logged in!
==> SYST ...
--> SYST
215 Windows_NT
done. ==> PWD ...
--> PWD
257 "/" is current directory.
done.
==> TYPE I ...
--> TYPE I
200 Type set to I.
done. changing working directory
Prepended initial PWD to relative path:
pwd: '/'
old: 'sysman'
new: '/sysman'
==> CWD (1) /sysman ...
--> CWD /sysman
250 CWD command successful.
done.
==> SIZE sm_6.5.0-15_A00.2.iso ...
--> SIZE sm_6.5.0-15_A00.2.iso
213 2888771584
2888771584
conaddr is: 143.166.11.10
==> PASV ...
--> PASV
227 Entering Passive Mode (143,166,11,10,201,249)
trying to connect to 143.166.11.10 port 51705
seconds 0.00, Created socket 4.
done. ==> REST -1876255751 ...
--> REST -1876255751
501 Reply marker is invalid.
REST failed, starting from scratch.
==> RETR sm_6.5.0-15_A00.2.iso ...
--> RETR sm_6.5.0-15_A00.2.iso
125 Data connection already open; Transfer starting.
done.
Length: 2888771584 (2.7G) (unauthoritative)
0% [ ] 0 --.-K/s in 0.3s
sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
Closed fd 3
Closed fd 4
I see, just realized that my wget don't have large-file support from "wget -V" will try recompile.
Thanks for reports :)
M:\temp>wget -c ftp://dstrr:dstrr@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
ReplyDelete--2011-12-05 11:09:17-- ftp://dstrr:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:21... connected.
Logging in as dstrr ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> EPSV ... done. ==> REST 2127124346 ... done.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G), 761647238 (726M) remaining (unauthoritative)
74% [+++++++++++++++++++++++++++++++++++++++++> ] 2 145 974 138 44,9M/s
C
at this point i pressed Ctrl+C and breaked download
Now i trying to resume
M:\temp>wget -c ftp://dstrr:dstrr@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
--2011-12-05 11:09:19-- ftp://dstrr:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
=> `sm_6.5.0-15_A00.2.iso'
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:21... connected.
Logging in as dstrr ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
==> EPSV ... done. ==> REST -2139669990 ...
REST failed, starting from scratch.
==> RETR sm_6.5.0-15_A00.2.iso ... done.
Length: 2888771584 (2,7G) (unauthoritative)
0% [ ] 0 --.-K/s in 0,04s
sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
please see, first run
==> EPSV ... done. ==> REST 2127124346 ... done.
this is correct resume point
second run
==> EPSV ... done. ==> REST -2139669990 ...
file size is 2155297306. what is -2139669990?
Thank You
nah silly me that large-file support isn't related that's for 64bit proc only. Since SIZEOF_OFF_T is 4 for 32bit...
ReplyDeleteanyway the different REST is interesting (which is incorrect). Somehow REST at ftp scientific linux return resumable value.
Will try at home later...
Thanks
This problem is stat() used from gnulib (since wget 1.12) and always return the wrong filesize (st_size) if larger than 2GB. I'll try look deeper in the weekend...
ReplyDeleteHi thanks for the build, 1.11 had some problems with sourceforge these days.
ReplyDeleteBut one problem is, your wget creates a empty file on a 404 instead of no file. And our scripts then keep pretending the file was already downloaded.
Cheers
@anon
ReplyDeletefixed by forcing wget to use win32's _stat64 instead of gnulib's posix stat(). patched mswindows.h attached
@TheOneRing
give me your wget command first, I can't reproduce it
v:\dev-utils\bin\wget.exe --no-check-certificate -c -t 10 -O t:\kdelibs-4.7.4.tar.bz2 ftp://ftp.kde.org/pub/kde/stable/4.7.4/src/kdelibs-4.7.4.tar.bz2
ReplyDeletemaybe it's caused by the -O paramenter
I agree that if the filesize 0 wget should delete it after received 404, dunno why they do this...
ReplyDeleteas a workaround use -P t:\ instead of -O
hm yes but some urls we use are stuff like bitbucket.../1.0.1 and we have to rename them to tar.gz or stuff like that
ReplyDeleteThanks a lot for fixing the 2GB bug!
ReplyDeleteThanks dude, this made my day!
ReplyDeleteHi mate! Can you add this patch to WGET? Set stdout to binary...
ReplyDeletehttp://lists.gnu.org/archive/html/bug-wget/2009-05/msg00002.html
Thanks a lot!
ReplyDeleteNew release of Wget-1.14. Can you build it? Thanks!
ReplyDeleteupdated, but unteested, I'd rather wait for 1.14.x bugfix release though.
DeleteThanks for the head up!
wget 1.15 any time soon?
ReplyDeleteJust checked it, there is no 1.15 yet. I think you misunderstand, this is just unofficial build, I'm no wget developer, you should check their homepage http://www.gnu.org/software/wget/ instead
DeleteGreetings, TumaGonx Zakkum
ReplyDeleteCan You, please, recompile wget to lastest git source because of two issues:
1. "Bad file descriptor" error if "-c" and unspecified lenght (fixed in commit b1838bdf from 14.11.2012) (cause problem when mirroring sites).
Test command "wget -c www.google.com && wget -c www.google.com".
2. Unlink() function give error if file busy in win32. Possible solution - replace unlink() with DeleteFile() or just comment checking at strings 1152/1153 (if (unlink (filename) < 0) return NULL;) in warc.c. Both solution cause non-deleted temporary files (but WARC begin to work).
Test command - "wget --warc-file=1 www.google.com"
And, please, can You describe, how do You compile so small file? I tried to compile wget, but recieve 4,5Mb (non-UPX) size - 500 kB Wget + 3Mb SSL + 1Mb Iconv (Looks like You use WinIconv instead)
Best regards.
PS. Sorry for bad English.
Thanks dude the report and workaround,
Deleteis [1] a new bug for 1.14 or to all version? and about [2] I dunno know what to say, considering there is a defect... maybe you could consult it with the devs first cause I'm not familiar with warc.
That said, personally I'd rather wait for final bugfix release and I think (just a feeling) they're gonna make it soon... ah here you go:
http://osspack32.googlecode.com/files/wget-git090313.exe
untested as usual
Why so small? Well, I'm addicted to squeeze it. What's your flags? have you tried my flag from wget -V?
Greetings
DeleteGreat Thanks!
About issues - [1] exist only in 1.14. [2] - only in MinGW. Even in CygWin it (method of creation temporary files) work fine. Ok, I'll try to post it.
About build - More Thanks.
If i try to compile with CPFLAGS="-Os -s" + "upx --best --ultra-brute" (25% less than upx -9), i recieve - 2.9 Mb uncompressed/ 1.1 Mb UPXed (sorry, 4.5 Mb was with "-g" and , sure, without "--strip" key during debug). And 1.7/0.6 Mb without Iconv (with Win_Iconv. You sure use it).
Compiled in fresh MinGW (only used mingwrt-3.18-mingw32_file64.diff patch) by string
[code]./bootstrap && ./configure --with-ssl=openssl --with-libidn=/usr/local --with-libiconv-prefix=/usr/local --with-libssl-prefix=/usr/local/ssl --with-libintl-prefix=/usr/local CFLAGS="-DLARGEFILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_PC_NAME_MAX=255 -Os -s -msse2" LDFLAGS="-static -s" && make && make check[/code]
Sorry for time waste.
I see... Now thats more realistic, BTW did you enable regex (via PCRE)? and fnmatch? they have no specific option to enable but autodetected by configure. If you also enable them then the difference could be:
Delete1. You're using mingw from mingw32.org, which is dwarf-2 based, which has extra debugging section per object file which you can't get rid of them unless using special flags "-fno-unwind-tables -fno-asynchronous-unwind-tables". I use mingw-w64 with SJLJ (no need for 64bit offset patch too)
2. Because I build my gcc with "-Os" optimized libgcc and crt
However if you don't enable them, the difference is still big... OpenSSL contribute the largest portion, how you build it, did you enable zlib, which version?
ultra-brute? Oh you're crazy, how long it takes? I can't stand that single threaded UPX to finished using my 2 Ghz cpu.
DeleteGreetings
ReplyDeleteGreat thanks for helping. After recompiling all with "-fno-unwind-tables -fno-asynchronous-unwind-tables" resulting size is 595Kb, (version with pcre - 620 Kb.) https://dl.dropbox.com/u/27457022/wget_nightly_wi.zip
OpenSSL1.0.1e + zlib 1.2.7
--ultra-brute UPX working with wget around 15 min. (30 min bootstrap + 10 min configure + 10 min build + 15 min UPX).
A thousands more thanks!
Best regards.
It seems to be flagged as a virus by VirusTotal:
ReplyDeletehttps://www.virustotal.com/en/file/cf8a9b5db43dd4820ea28e10786f3fac00cf294f793ead1aef86de75246f4495/analysis/
Then help me to unflag it :)
Deletehttp://opensourcepack.blogspot.com/2013/03/list-of-upx-illiterate-antivirus.html
http://dl.dropboxusercontent.com/u/33728474/wget-1.13.4/locale.7z
ReplyDeleteand
http://dl.dropboxusercontent.com/u/33728474/wget-1.13.4/curl-ca-bundle.crt
" ... are generating too much traffic and have been temporarily disabled! "
Please upload elsewhere, thanks.
There is a new version of wget 1.15. http://ftp.gnu.org/gnu/wget/wget-1.15.tar.xz. Can you compile it. Thanks.
ReplyDeleteThanks for the head up, will do.
DeleteWhere could we download a compiled binary, sir?
DeleteI tested this thoroughly. 1.15 (and the old 1.11.4) have same bug with timestamps:
ReplyDeletewget -N -O "hostsbadstamp" http://someonewhocares.org/hosts/zero/hosts
timestamp of the -O output file is not updated.
wget -N http://someonewhocares.org/hosts/zero/hosts
timestamp is updated without the -O
Could you file bugreport to wget team to confirm it?
Deleteit seems not exactly the same issue reported earlier (which already fixed upstream).
thanks
ahh did you read the message?
DeleteWARNING: timestamping does nothing in combination with -O. See the manual
Wget 1.16 new release. Could you compile it for windows. Thanks.
ReplyDeleteGet latest versions from https://eternallybored.org/misc/wget/
ReplyDeleteNew wget 1.16.2 today. Could you make windows release? Ty.
ReplyDeletewget 1.16.3
ReplyDeleteХерня красноглазая, блядь.
ReplyDeleteHOW TO BUILD FOR WINDOWS ?
where is source code, which has been changed ?
Wget 1.17 appeared today. Thanks.
ReplyDeleteCan you build curl-7.46.0 and wget 1.17.1. Thanks.
ReplyDeleteWget 1.18 and curl 7.49.1 just appeared. Ty.
ReplyDeleteWget 1.19 ready
ReplyDeletewget 1.19.1 was released. TY
ReplyDeleteWget 1.19.2 ;)
ReplyDeleteWGET 1.19.4
ReplyDeleteCan you build aria2c 1.33.1? This release fixes a bug that causes high CPU usage in mingw build 1.33.0.
ReplyDelete