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 -#include +#include +#include +#include +#include +#include +#include +#include +#include ], [ 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
Keith Moore <[EMAIL PROTECTED]> writes: >> No, there isn't. Sorry. [...] > So, there's the answer. Cygwin's POSIX timer support is incomplete. Then why on earth do they #define _POSIX_TIMERS? It's easy enough to add a configure test for clock_getres, but it's damn annoying to have to do so in the brave new world of POSIX. I'd rather simply have sysdep.h #undef _POSIX_TIMERS under Cygwin.
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
