Re: wget and seeding random numbers
1 - Use RAND_egd() for reading true random data if such is available (this needs to be checked for in the configure script, as RAND_egd() wasn't introduced until OpenSSL 0.9.5). This would also benefit from a command line option to specify the egd socket. EGD = Entrophy Gathering Daemon. 2 - Use RAND_screen() for windows based systems (gets random data off the screen). 3 - Allow a user-specified file for reading random data from with RAND_load_file() 4 - Use RAND_file_name() to get what default file (if any) to read random data from. (This seems to be done in the lynx code) 5 - *then* you go with the srand(), time and pid seeding stuff. I'm no expert on openssl, but that looks pretty reasonable, and it's probably just a couple more calls, so not hard to do? As long as the srand()all stuff is there as a final default. Thanks, karl
Re: wget and seeding random numbers
[EMAIL PROTECTED] writes: 1 - Use RAND_egd() for reading true random data if such is available (this needs to be checked for in the configure script, as RAND_egd() wasn't introduced until OpenSSL 0.9.5). This would also benefit from a command line option to specify the egd socket. EGD = Entrophy Gathering Daemon. 2 - Use RAND_screen() for windows based systems (gets random data off the screen). 3 - Allow a user-specified file for reading random data from with RAND_load_file() 4 - Use RAND_file_name() to get what default file (if any) to read random data from. (This seems to be done in the lynx code) 5 - *then* you go with the srand(), time and pid seeding stuff. I'm no expert on openssl, but that looks pretty reasonable, It does, but I've never done any SSL coding so I'll probably not get around to it soon. Also, this kind of change will not make it to 1.7.1.
Re: GNU Wget 1.7 is released
On 14 Jun 2001 22:43:17 +0200, Hrvoje Niksic [EMAIL PROTECTED] wrote: I downloaded wget-1.7, when I tried to configure it, I received an error. I found the error was in ltconfig, because the variable `ORIGINAL_CONFIG_SHELL' was not set. Setting this variable outside the if solved the problem. The diff is below. What system are you using? I find it curious that nobody else has reported this. It is on Red Hat 6.0 Linux, which is kind of old (current RH version is 7.1). I use bash 2.03.01. I will upgrade, but not too soon. I am loathe to change `ltconfig' because it is maintained outside Wget. However, since the upgrade to the next libtool release is scheduled for after 1.7.1, I might apply your patch as a stop-gap fix. If nobody else has encountered this problem, then may be something is wrong with my system/bash. Ehud. -- Ehud Karni Mivtach - Simon Insurance /"\ Tel: +972-3-6212-757 Fax: +972-3-6292-544 \ / ASCII Ribbon Campaign (USA) Fax and voice mail: 1-815-5509341X Against HTML Mail Better Safe Than Sorry / \ mailto:[EMAIL PROTECTED]http://www.simonwiesel.co.il
Re: ftp,proxy and .netrc problem
Hi, Hrvoje Niksic wrote: [snip] Sorry for not responding -- I was a bit busy after the release. Of course, it was perfectly fine to include the logs, they were certainly not the reason for ignoring the mail! Thats okay don't worry. Rick wget ftp:[EMAIL PROTECTED]/dl/a.a and I have a .netrc, would you expect wgetrc to look for the remote user / password (i.e. the password for rick at a.machine.com) in the .netrc file? I would but it doesn't - it searches the .netrc file for an entry associated with my proxy machine!? This is a bug. Does this patch fix the problem? I applied the patch over lunchtime and gave it a quick try and it seems to be working. I'll try a few more tests when I get some more time. Thanks for the response. I'm glad it was a bug that could be easily fixed rather than me not understanding how things were supposed to work! :-) Regards, -- Richard Travett,Email: [EMAIL PROTECTED] May all your communications be free from electro-magnetic disturbances, and your days be free from temporal distortions in the space time continuum This email does not represent a formal communication from Simoco. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
wget-1.7 + SSL: ./configure fails
partial output from ./configure --with-ssl=/usr/local/ssl: checking for runtime libraries flag... -rpath checking for dlopen in -ldl... yes checking for shl_load in -ldl... no Looking for SSL libraries in /usr/local/ssl checking for RSA_new in -lcrypto... no checking for SSL_new in -lssl... no WARNING: Failed to link with OpenSSL libraries in /usr/local/ssl/lib. Wget will be built without support for https://... URLs. ...relevant section from config.log: configure:3660: checking for RSA_new in -lcrypto configure:3679: gcc -o conftest -g -O2 -L/usr/local/ssl/lib -rpath /usr/local/s sl/lib conftest.c -lcrypto 15 gcc: unrecognized option `-rpath' /usr/local/ssl/lib: file not recognized: Is a directory collect2: ld returned 1 exit status snip Looks like it should be -r /usr/local/ssl/lib rather than -rpath /usr/local/ssl/lib (but I'm not familiar enough with GNU autoconf to know how to fix it properly)... Actually... -r /usr/local/ssl/lib is still wrong, the -r option takes a file name, not a directory... also... messing with the -r option to gcc, I notice the space after -r is required (-r/usr/local/ssl/lib gives me `unrecognized option'), I guess that could be considered a bug in gcc.. this behavior occurs with both egcs-2.91.66 and 2.95.3 (yes, openSSL-0.9.6a is properly installed in /usr/local/ssl on both of the boxes I'm trying to build wget on) B. Watson Network Administrator Linux General Store, Inc.
Re: wget-1.7 + SSL: ./configure fails
B. Watson [EMAIL PROTECTED] writes: partial output from ./configure --with-ssl=/usr/local/ssl: [...] Thanks for the report; this will be fixed in the next release.
wget-1.7 ./configure
Re my previous message: editing the configure.in and commenting out the whole
section containing the `dash_r' test (beginning at line 206) and running
autoconf to generate a new configure script, works fine on my systems (both
are Linux boxes, one with GNU libc-2.1.3 and egcs-2.91.66 and the other with
libc-2.2.2 and egcs-2.95.3)
I dunno what else this might impact... let me try it on my solaris 7 box...
(some minutes later)
The solaris box doesn't have the problem in the first place... here's the
appropriate section from configure.in, beginning at line 206:
AC_MSG_CHECKING(for runtime libraries flag)
case $host_os in
sol2 ) dash_r=-R ;;
decosf* | linux* | irix*) dash_r=-rpath ;;
*)
dash_r=
for try_dash_r in -R -R -rpath ; do
OLD_LDFLAGS=$LDFLAGS
LDFLAGS=${try_dash_r}/no/such/file-or-directory $LDFLAGS
AC_TRY_LINK(, , dash_r=$try_dash_r)
LDFLAGS=$ODL_LDFLAGS
test -n $dash_r break
done ;;
esac
if test -n $dash_r;
then AC_MSG_RESULT(\${dash_r}\)
else AC_MSG_RESULT(NONE)
fi
my Solaris 7 machine is using egcs-2.95.3, same as one of the Linux boxes...
why is $host_os used to determine which flag to pass, since the flag is the
same on gcc, regardless of which OS it's running on? Hard-coding the dash_r
flag to -R fixes the problem on the 2 Linux machines (and had no effect on
the Solaris machine)...
I don't have any other compilers to try this on other than gcc/egcs, so I
don't know how that would affect them...
(p.s. in my earlier message I stated I wasn't familiar with GNU autoconf, I'm
still not, so feel free to take everything I say with a huge grain of salt!)
B. Watson
Network Administrator
Linux General Store, Inc.
1.7.1-pre1 on NCR MP-RAS: success
Executive summary: complete success. On NCR MP-RAS, Wget 1.7.1-pre1 configured and compiled fine, and passed a few simple tests. The -lnsl/-lsocket and MAP_FAILED problems seen with previous versions did not occur. No SSL library is installed on the system. ./configure --with-ssl detected that correctly. The resulting executable worked fine with HTTP. For https: URLs, it prints Unknown/unsupported protocol and exits. A binary made with plain ./configure without --with-ssl exhibits the same exact behaviour. Should you need the logs, they're at http://www.teaser.fr/~amajorel/mpras/jp/wget-1.7.1-pre1.config.log.gz http://www.teaser.fr/~amajorel/mpras/jp/wget-1.7.1-pre1.config.log.with-ssl.gz Thanks to everyone involved. -- André Majorel Work: [EMAIL PROTECTED] Home: [EMAIL PROTECTED] http://www.teaser.fr/~amajorel/
Re: wget-1.7 ./configure
B. Watson [EMAIL PROTECTED] writes: my Solaris 7 machine is using egcs-2.95.3, same as one of the Linux boxes... why is $host_os used to determine which flag to pass, since the flag is the same on gcc, regardless of which OS it's running on? This is not true. -R definitely doesn't work on Linux, at least on my system. It requires something like `-Wl,-rpath'. It may have worked for you because Wget 1.7 uses libtool to link and libtool transformed -R into the proper incantation. (This path lies the solution we've ended up using.) And why is the whole -R thing needed? Because -L is often not sufficient to create a working executable. It tells the linker where to find the dynamic library at *link*-time, but fails to store that information in the binary. The result is a seemingly correct build, but the executable mysteriously failing when you try to run it. But as you discovered, auto-detecting the proper -R flag is hard because it differs across systems, compilers, and linkers. Since Wget uses libtool anyway, we've modified the configure script to link with libtool when check for the libraries at configure-time, so configure can now get away with using -R, which is processed by libtool. This is all pretty convoluted, so don't worry if it doesn't make sense. The bottom line is, the next release *should* behave properly. If you want to test it, download it from ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.7.1-pre1.tar.gz
Re: 1.7.1-pre1 on NCR MP-RAS: success
Andre Majorel [EMAIL PROTECTED] writes: Executive summary: complete success. [...] Thanks a lot for testing.
Boost Your Windows Reliability........ 17412
Dear Windows User, Now you can boost the reliability of ordinary Windows 95, 98 and ME to nearly the level of Windows NT or 2000, Microsoft's professional and industrial version of Windows. The new WinFix is a very effective way to improve the reliability of Windows, because it makes Windows fault-tolerant and self-repairing. And WinFix is very safe, because it operates completely independent of Windows. CLICK HERE to find out more about WinFix, the safest, most effective way to keep you working, by keeping your PC working non-stop. Arlen Dixon, CEO Pinewood Software Marketing --- This announcement is intended for PC users who asked to be kept informed about new developments in Windows technology. To be removed from future mailings, please reply with REMOVE in the subject line.
