Re: Compile problem with OpenSSL 0.9.5a
[EMAIL PROTECTED] (Larry Jones) writes: Trying to compile the current CVS, I get the following compile error: gcc -I. -I. -I/usr/local/ssl/include -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\/usr/local/etc/wgetrc\ -DLOCALEDIR=\/usr/local/share/locale\ -O2 -Wall -Wno-implicit -c http-ntlm.c http-ntlm.c:50: openssl/md4.h: No such file or directory *** Error code 1 This system has OpenSSL 0.9.5a installed which doesn't have md4.h (although it does have md2.h and md5.h). I realize 0.9.5a is very old, but you might want to consider beefing up the configure test to make sure that it has *all* the SSL files it needs before automatically enabling SSL. Currently it just looks for ssl.h and rsa.h (which isn't even used anywhere that I can find) but the code also uses bio.h, crypto.h, x509.h, err.h, pem.h, rand.h, des.h, md4.h, and md5.h. 0.9.5a is five years old and would normally not be supported (you can always specify --without-ssl to avoid it), but this is easy enough to fix, so here goes: 2005-04-08 Hrvoje Niksic [EMAIL PROTECTED] * configure.in: When checking for OpenSSL headers, check for all the ones that Wget is using. Index: configure.in === RCS file: /pack/anoncvs/wget/configure.in,v retrieving revision 1.77 diff -u -r1.77 configure.in --- configure.in2005/04/07 23:41:08 1.77 +++ configure.in2005/04/08 09:41:15 @@ -327,10 +327,20 @@ ssl_found_includes=no CPPFLAGS=$SSL_INCLUDES $wget_save_CPPFLAGS +dnl Check for all the OpenSSL includes that Wget actually uses. +dnl This will prune both invalid installations and ancient +dnl versions of OpenSSL that we can't use. AC_MSG_CHECKING([for includes]) AC_COMPILE_IFELSE([ #include openssl/ssl.h -#include openssl/rsa.h +#include openssl/bio.h +#include openssl/crypto.h +#include openssl/des.h +#include openssl/err.h +#include openssl/md4.h +#include openssl/pem.h +#include openssl/rand.h +#include openssl/x509.h ], [ AC_MSG_RESULT(found) ssl_found_includes=yes
RE: NTLM authentication in CVS
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] 3) As expected msvc still throws compiler error on http.c 1. Is it possible to only lessen the optimization level, not entirely remove optimization? Fooled around a bit, didn't accomplish anything. However it is enough disabling the optimization for those two functions, only. 2. Is it possible to test for the offending version of the compiler, and only then remove optimization? Since Tobias (thanks!) confirmed v13 works yes. The enclosed patch disables for _MSC_VER=1200, if other reports should come in maybe we can restrict the test further. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax 20050408.diff Description: Binary data
Problems building current CVS version under Cygwin
I downloaded the CVS version of wget today and tried to build it under
the latest (1.15-14) Cygwin. I hit two compilation problems, both in
src/ptimer.c.
1. The first problem is with the test for _POSIX_MONOTONIC_CLOCK on line
186. That line is:
#if _POSIX_MONOTONIC_CLOCK = 0/* -1 means not supported */
Under Cygwin, _POSIX_MONOTONIC_CLOCK is not defined, so cpp uses a
default value of 0 in the test. This causes the test to succeed, and
ptimer.c tries to compile sysconf(_SC_MONOTONIC_CLOCK) which fails.
A fix (but possibly not the most portable fix) for this is to change the
test:
#if defined(_POSIX_MONOTONIC_CLOCK) (_POSIX_MONOTONIC_CLOCK = 0)
2. The second problem is a little more annoying. Under Cygwin,
clock_getres() is properly defined in time.h, but there is no librt.a to
resolve the reference. A possible workaround is to a) add a test for
clock_getres to aclocal.m4, and b) wrap the code in ptimer.c that calls
clock_getres() in a #if HAVE_CLOCK_GETRES conditional.
I have attached a patch implementing these two fixes, if anyone is
interested.
With these two problems resolved, the CVS version of wget is running
great under Cygwin. In a day or two, I should know if the 2G file
support is working as well...
Thanks!
KM
diff -ur wget.orig/aclocal.m4 wget/aclocal.m4
--- wget.orig/aclocal.m42005-04-08 01:41:08.0 +0200
+++ wget/aclocal.m4 2005-04-08 16:14:40.078125000 +0200
@@ -85,6 +85,9 @@
AC_CHECK_FUNCS(clock_gettime, [], [
AC_CHECK_LIB(rt, clock_gettime)
])
+ AC_CHECK_FUNCS(clock_getres, [], [
+AC_CHECK_LIB(rt, clock_getres)
+ ])
])
dnl Check whether we need to link with -lnsl and -lsocket, as is the
diff -ur wget.orig/src/ptimer.c wget/src/ptimer.c
--- wget.orig/src/ptimer.c 2005-04-08 14:09:02.046875000 +0200
+++ wget/src/ptimer.c 2005-04-08 15:10:27.25000 +0200
@@ -183,13 +183,14 @@
{
struct timespec res;
-#if _POSIX_MONOTONIC_CLOCK = 0 /* -1 means not supported */
+#if defined(_POSIX_MONOTONIC_CLOCK) (_POSIX_MONOTONIC_CLOCK = 0) /* -1
means not supported */
if (sysconf (_SC_MONOTONIC_CLOCK) 0)
posix_clock_id = CLOCK_MONOTONIC;
else
#endif
posix_clock_id = CLOCK_REALTIME;
+#if HAVE_CLOCK_GETRES
if (clock_getres (posix_clock_id, res) 0)
{
logprintf (LOG_NOTQUIET, _(Cannot read clock resolution: %s\n),
@@ -198,6 +199,10 @@
res.tv_sec = 0;
res.tv_nsec = 100;
}
+#else
+ res.tv_sec = 0;
+ res.tv_nsec = 100;
+#endif
posix_resolution = res.tv_sec * 1000.0 + res.tv_nsec / 100.0;
/* Guard against clock_getres reporting 0 resolution; after all, it
Re: Problems building current CVS version under Cygwin
Keith Moore [EMAIL PROTECTED] writes: I downloaded the CVS version of wget today and tried to build it under the latest (1.15-14) Cygwin. Thanks for the report. Please note that ptimer.c has undergone additional changes today, so you might want to update your source. 1. The first problem is with the test for _POSIX_MONOTONIC_CLOCK on line 186. That line is: #if _POSIX_MONOTONIC_CLOCK = 0/* -1 means not supported */ Under Cygwin, _POSIX_MONOTONIC_CLOCK is not defined, so cpp uses a default value of 0 in the test. That has since been fixed, much the way you describe. 2. The second problem is a little more annoying. Under Cygwin, clock_getres() is properly defined in time.h, but there is no librt.a to resolve the reference. I don't get it -- if clock_getres is unavailable, then why does Cygwin declare support for POSIX timers? Maybe we should simply use gettimeofday, or even Windows timers, under Cygwin?
Re: Problems building current CVS version under Cygwin
Hrvoje Niksic wrote: Thanks for the report. Please note that ptimer.c has undergone additional changes today, so you might want to update your source. Will do. I don't get it -- if clock_getres is unavailable, then why does Cygwin declare support for POSIX timers? Maybe we should simply use gettimeofday, or even Windows timers, under Cygwin? I cannot answer that question. I will post it to the Cygwin list and provide any answers here. FWIW - POSIX timers appear to be partially supported. clock_gettime() is present, but there is no librt.a, so it's in a nonstandard place (unless I am totally missing something). KM
Re: Problems building current CVS version under Cygwin
Keith Moore [EMAIL PROTECTED] writes: FWIW - POSIX timers appear to be partially supported. clock_gettime() is present, but there is no librt.a, so it's in a nonstandard place (unless I am totally missing something). Wget doesn't require clock_gettime to be exactly in librt.(so|a), but it has to be *somewhere*. But if I understand your first report, the problem is not the lack of clock_gettime, but of clock_getres, and that's what Wget is not prepared to handle. It (naively) assumes that, if the implementation defines _POSIX_TIMERS, that they are actually implemented. Serves me right for trying to use an API designed after 1985.
Re: Problems building current CVS version under Cygwin
Hrvoje Niksic wrote: Keith Moore [EMAIL PROTECTED] writes: FWIW - POSIX timers appear to be partially supported. clock_gettime() is present, but there is no librt.a, so it's in a nonstandard place (unless I am totally missing something). Wget doesn't require clock_gettime to be exactly in librt.(so|a), but it has to be *somewhere*. But if I understand your first report, the problem is not the lack of clock_gettime, but of clock_getres, and that's what Wget is not prepared to handle. It (naively) assumes that, if the implementation defines _POSIX_TIMERS, that they are actually implemented. Serves me right for trying to use an API designed after 1985. Yes, it's the missing clock_getres() that's the problem. I asked about this on the Cygwin list, and I received a quick (if brief) reply: Christopher Faylor wrote: On Fri, Apr 08, 2005 at 10:32:19PM +0200, Keith Moore wrote: /usr/include/sys/features.h defines _POSIX_TIMERS, presumably to indicate that POSIX timers are supported. There seems to be something missing, though. Under the influence of _POSIX_TIMERS, /usr/include/time.h defines function prototypes for clock_gettime() and clock_getres() (and a few others). clock_gettime() gets linked-in from libc.a, but I cannot find a library for clock_getres(). This is causing problems for the CVS version of wget, which assumes _POSIX_TIMERS means all of the POSIX timer APIs are supported. Am I missing something here? Is there a clock_getres() somewhere? No, there isn't. Sorry. So, there's the answer. Cygwin's POSIX timer support is incomplete. I'm not a Cygwin expert, but I suspect getting this API added would not be too terribly painful. However, even if that were to happen, it would mean wget would require a recent (and currently undeveloped/untested/unreleased) version of Cygwin to run in the Cygwin environment. Bummer. If there's anything I can do to help, please let me know. For example, I can do regular sanity test builds under Cygwin. Thanks for wget! KM
Re: Problems building current CVS version under Cygwin
I've now fixed this by simply having Cygwin use the Windows high-res timers, which are very precise. When Cygwin is fixed, we can revert it to use POSIX timers, like god intended.
Re: --keep-session-cookies ???
On Thursday 03 March 2005 09:07 am, Hrvoje Niksic wrote: Brad Andersen [EMAIL PROTECTED] writes: This option appears to be missing from wget --help, however, it is in the documentation. It is not working in 1.9 or 1.9.1. That option will first appear in Wget 1.10 and is currently available in CVS. Where did you find documentation that advocates it? i think this is my fault. the wget manual i uploaded on gnu.org is from a cvs version of wget i checked out last november. i will upload the correct version this weekend. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
