Ray Satiro <raysat...@yahoo.com> writes: > Is there a web interface for the new repository? Somewhere we'll be able to > click a link and download a zip of different revisions, like > the old repository. I couldn't find it so I tried bazaar 2.1.1 for windows > but it tells me the wget tree isn't available and I can't pull > anything: > > This branch has no working tree. Last revision is 2359. Action not yet > supported by current app_suite.
can you try this command? "bzr branch http://bzr.savannah.gnu.org/r/wget/trunk" You will also need git and rsync installed for the `boostrap' script. > As for msys fixes I see you fixed the linking issue in the last revision, > bravo :) ipv6 and ssl config tests are still broken. In windows > if you are going do a static link test for openssl you should link with > winsock2 (openssl now uses winsock2) and gdi as well. So this will > work: > > gcc a.c -lssl -lcrypto -lws2_32 -lgdi32 > > regardless when wget is compiled with-ssl using mingw one would expect that > instead of ssl crypto gdi it not be linked to any of those, > just to eay32 and ssl32 (openssl dlls). > > also the config ac shows lwsock32 -lws2_32 and indeed on compile both are > linked. is there any reason for this, like maybe a trick for a > universal binary or something? it doesn't seem logical. > AFAIK, -lws2_32 is needed to build successfully, is there a way to don't use it? > ipv6 fix is a little different and this goes to an argument that's come up > before where if you are going legacy there apparently is a way > to make a universal binary so that wget built with ipv6 support could? > function on windows systems with winsock 1.1. well ok but really is > wget set up for this and is it possible and is there any reason for it? i > don't get that. regardless config is testing for getaddrinfo > which is only winsock2, and according to the tcpip header file I have for it > actually to be declared _WIN32_WINNT >= 0x0501. my suggestion > is continue to test for getaddrinfo but fix for mingw > I will take a look at these issues ASAP. I think we can declare _WIN32_WINNT >= 0x0501 without big problems. Thanks, Giuseppe