Re: [Bug-wget] wget for windows - current build?
On Sonntag, 2. Oktober 2016 10:11:33 CEST Eli Zaretskii wrote: > > From: Tim Rühsen > > Cc: ge...@mweb.co.za > > Date: Sat, 01 Oct 2016 20:12:28 +0200 > > > > If you like to create a README.windows maybe with (basic) explanations on > > how to build wget on Windows plus pointers to your port(s), we include it > > into the project. > > That's okay (will do when I have time), but I think it would be more > useful to have a link on the Wget Web page to the places where Windows > binaries can be found. Basically we only provide source code plus recipes how to build binaries. IMO, it is ok to link to places where one can download ready-to-go binaries - as long there is also a recipe for users to (re-)generate these binaries on their own. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] wget for windows - current build?
On Fri, 30 Sep 2016, ge...@mweb.co.za wrote: > So, is there a "secret" new place hosting a newer version for Windows? > Or is the 1.11 on sourceforge actually okay? And - while I am already In addition to the Windows port Eli makes available, there are also 32 bit and 64 bit Windows binaries available from Jernej Simoncic at "https://eternallybored.org/misc/wget/";. The latest version there is 1.18. Doug -- Doug Kaufman Internet: dkauf...@rahul.net
Re: [Bug-wget] wget for windows - current build?
> From: Tim Rühsen > Cc: ge...@mweb.co.za > Date: Sat, 01 Oct 2016 20:12:28 +0200 > > If you like to create a README.windows maybe with (basic) explanations on how > to build wget on Windows plus pointers to your port(s), we include it into > the > project. That's okay (will do when I have time), but I think it would be more useful to have a link on the Wget Web page to the places where Windows binaries can be found. > BTW, meanwhile libidn fixed several security issues, as well as gnutls, > libpsl > and wget itself ;-) Duly noted.
Re: [Bug-wget] wget for windows - current build?
On Samstag, 1. Oktober 2016 20:27:47 CEST Eli Zaretskii wrote: > > From: Tim Rühsen > > Cc: ge...@mweb.co.za > > Date: Sat, 01 Oct 2016 18:10:26 +0200 > > > > > > It shouldn't be too hard to write a script that cross-compiles wget > > > > and > > > > some dependencies via mingw. But would such an .exe really work on a > > > > real > > > > Windows machine ? > > > > > > I'm not sure I understand the question. If cross-compiling works, > > > then why won't the result run as expected? > > > > Well, some years ago I copied cross compiled executables (32bit) onto a > > WinXP machine. Executing these didn't error, but they immediately > > returned without doing anything. Even the first printf() line didn't do > > anything. > > While executing the same executables with wine on the machine that I used > > for compilation, they worked fine. > > Sounds like some incompatibility between the import libraries you had > in that cross-environment and the corresponding DLLs on the target > Windows XP machine. > > > While it seems pretty easy to generate a wget.exe on Linux and even run it > > through wine, it seems not to work out that easily on a real Windows. At > > least these questions for a recent Windows executable are pretty common - > > and the Windows affine users here do not have a easy solution as it > > seems. > Building Wget on Windows is easy if you have an operational > development environment. What's not easy is running the test suite > and figuring out what each failure means, then fixing the sources as > needed. > > Anyway, in addition to my site, which offers a 32-bit build, the MSYS2 > project offers both 32-bit and 64-bit builds (although I cannot vouch > for their thoroughness in running the test suite -- not that I know > they didn't, mind you). People who ask about that must be doing that > out of ignorance; perhaps we should include pointers to those places > in the distribution. Sounds good :-) If you like to create a README.windows maybe with (basic) explanations on how to build wget on Windows plus pointers to your port(s), we include it into the project. BTW, meanwhile libidn fixed several security issues, as well as gnutls, libpsl and wget itself ;-) Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] wget for windows - current build?
> From: Tim Rühsen > Cc: ge...@mweb.co.za > Date: Sat, 01 Oct 2016 18:10:26 +0200 > > > > It shouldn't be too hard to write a script that cross-compiles wget and > > > some dependencies via mingw. But would such an .exe really work on a real > > > Windows machine ? > > > > I'm not sure I understand the question. If cross-compiling works, > > then why won't the result run as expected? > > Well, some years ago I copied cross compiled executables (32bit) onto a WinXP > machine. Executing these didn't error, but they immediately returned without > doing anything. Even the first printf() line didn't do anything. > While executing the same executables with wine on the machine that I used for > compilation, they worked fine. Sounds like some incompatibility between the import libraries you had in that cross-environment and the corresponding DLLs on the target Windows XP machine. > While it seems pretty easy to generate a wget.exe on Linux and even run it > through wine, it seems not to work out that easily on a real Windows. At > least > these questions for a recent Windows executable are pretty common - and the > Windows affine users here do not have a easy solution as it seems. Building Wget on Windows is easy if you have an operational development environment. What's not easy is running the test suite and figuring out what each failure means, then fixing the sources as needed. Anyway, in addition to my site, which offers a 32-bit build, the MSYS2 project offers both 32-bit and 64-bit builds (although I cannot vouch for their thoroughness in running the test suite -- not that I know they didn't, mind you). People who ask about that must be doing that out of ignorance; perhaps we should include pointers to those places in the distribution.
Re: [Bug-wget] wget for windows - current build?
On Samstag, 1. Oktober 2016 18:29:30 CEST Eli Zaretskii wrote: > > From: Tim Rühsen > > Cc: "ge...@mweb.co.za" > > Date: Sat, 01 Oct 2016 13:04:25 +0200 > > > > It shouldn't be too hard to write a script that cross-compiles wget and > > some dependencies via mingw. But would such an .exe really work on a real > > Windows machine ? > > I'm not sure I understand the question. If cross-compiling works, > then why won't the result run as expected? Well, some years ago I copied cross compiled executables (32bit) onto a WinXP machine. Executing these didn't error, but they immediately returned without doing anything. Even the first printf() line didn't do anything. While executing the same executables with wine on the machine that I used for compilation, they worked fine. I didn't have any time to investigate - but since then I remember cross- compilation as a theoretical thing without any practical use :-) While it seems pretty easy to generate a wget.exe on Linux and even run it through wine, it seems not to work out that easily on a real Windows. At least these questions for a recent Windows executable are pretty common - and the Windows affine users here do not have a easy solution as it seems. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] wget for windows - current build?
> From: Tim Rühsen > Cc: "ge...@mweb.co.za" > Date: Sat, 01 Oct 2016 13:04:25 +0200 > > It shouldn't be too hard to write a script that cross-compiles wget and some > dependencies via mingw. But would such an .exe really work on a real Windows > machine ? I'm not sure I understand the question. If cross-compiling works, then why won't the result run as expected?
Re: [Bug-wget] wget for windows - current build?
On Freitag, 30. September 2016 19:17:42 CEST Eli Zaretskii wrote: > > Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST) > > From: "ge...@mweb.co.za" > > > > So, is there a "secret" new place hosting a newer version for Windows? Or > > is the 1.11 on sourceforge actually okay? And - while I am already asking > > all these stupid questions - would that version actually handle larger > > file sizes already? > You can find a 32-bit Windows port of 1.16.1 here: > > https://sourceforge.net/projects/ezwinports/files/?source=navbar It shouldn't be too hard to write a script that cross-compiles wget and some dependencies via mingw. But would such an .exe really work on a real Windows machine ? Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] wget for windows - current build?
> Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST) > From: "ge...@mweb.co.za" > > So, is there a "secret" new place hosting a newer version for Windows? Or is > the 1.11 on sourceforge actually okay? And - while I am already asking all > these stupid questions - would that version actually handle larger file sizes > already? You can find a 32-bit Windows port of 1.16.1 here: https://sourceforge.net/projects/ezwinports/files/?source=navbar
[Bug-wget] wget for windows - current build?
Hi guys, I just checked, I believe the version of wget I am running is from 2003 (and I have been using it for much mich longer than that ...) At some point I even wrote scripts around wget batch jobs I used to run ... But I am kind of stuck in Windows. And things happen on a different time line there. Just the other day I noticed that I was getting no joy downloading certain files and only after that had happened a few times did I realize that the file size was shown as negative. That is something that I have seen when the number is too big as an unsigned integer to also be interpreted as a 2's complement integer in the available number of bits. And then it dawned on me that my old wget may not be up to files greater than, say, 2GB. Time for a new download. I am being pointed at sourceforge, even by the German c't magazine, which is usually pretty clued up. But I remember having heard bad things about sourceforge. And the version they offer is 1.11.4, whereas your version on gnu.org is 1.18 or so. So, is there a "secret" new place hosting a newer version for Windows? Or is the 1.11 on sourceforge actually okay? And - while I am already asking all these stupid questions - would that version actually handle larger file sizes already? Thanks, guys, Gerd (and I mustn't forget to send a note to c't as well ...)
