configuration, openssl
Hello, I have attempted to configure wget 1.7 with openssl. Openssl 0.9.6a is installed at /usr/local/ssl, with the libraries in the lib directory under that. Your INSTALL file says that this is standard enough that I need only use 'configure --with-ssl' for this to succeed, but upon running, this is partial resulting output: Looking for SSL libraries in default checking for RSA_new in -lcrypto... no checking for SSL_new in -lssl... no Looking for SSL libraries in /usr/local/ssl checking for RSA_new in -lcrypto... no checking for SSL_new in -lssl... no Looking for SSL libraries in /usr/local checking for RSA_new in -lcrypto... no checking for SSL_new in -lssl... no Looking for SSL libraries in /opt checking for RSA_new in -lcrypto... no checking for SSL_new in -lssl... no WARNING: Failed to link with OpenSSL libraries in /opt/lib. Wget will be built without support for https://... URLs. The contents of my /usr/local/ssl/lib directory: libcrypto.a libcrypto.so.0 libssl.a libssl.so.0 libcrypto.so libcrypto.so.0.9.6 libssl.so libssl.so.0.9.6 (the openssl distribution was built with all default paths, only additional option 'shared') Thanks for any help! --Tomki
Re: Please upgrade libtool in wget
Arkadiusz Miskiewicz [EMAIL PROTECTED] writes: and please fix aclocal.m4 (it contains wget specific macros which should be in acinclude.m4) I'm not buying that. I think it's perfectly fine to have Wget-specific macros in aclocal.m4. and also acconfig.h is missing (autoheader breaks on it). Don't use autoheader.
Re: wget 1.7 installation
Samer Nassar [EMAIL PROTECTED] writes: I am having trouble installing wget 1.7 on a solaris box. Here is part of what I am getting: In file included from log.c:31: /usr/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.8.0/include/stdarg.h:163: warning: redefinition of `va_list' /usr/include/stdio.h:118: warning: `va_list' previously declared here ... It looks like something very strange is going on with your Solaris system. Which version of Solaris is it? Have you upgraded Solaris since installing Gcc? Are you aware that 2.8.0 is a very old version of Gcc?
Re: configuration, openssl
Tomki [EMAIL PROTECTED] writes:
Looking for SSL libraries in default
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Looking for SSL libraries in /usr/local/ssl
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Hmm, we should investigate why this fails to link. It's supposed to
link with `-L/usr/local/ssl/lib -R/usr/local/ssl/lib'.
What operating system are you using?
Does linking this program work:
/* a.c */
int RSA_new();
int SSL_new();
main(){return 0;}
$ gcc a.c -L/usr/local/ssl/lib -lssl -lcrypto
$ ./a.out
Does this work:
$ gcc a.c -L/usr/local/ssl/lib -R/usr/local/ssl/lib -lssl -lcrypto
$ ./a.out
Re: configuration, openssl
At 12:29 6/5/2001 +0200, Hrvoje Niksic wrote:
Tomki [EMAIL PROTECTED] writes:
Looking for SSL libraries in default
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Looking for SSL libraries in /usr/local/ssl
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Hmm, we should investigate why this fails to link. It's supposed to
link with `-L/usr/local/ssl/lib -R/usr/local/ssl/lib'.
What operating system are you using?
Linux, originally from a Redhat 6.0 installation.
Kernel 2.2.18, GCC 2.95.2
Does linking this program work:
/* a.c */
int RSA_new();
int SSL_new();
main(){return 0;}
$ gcc a.c -L/usr/local/ssl/lib -lssl -lcrypto
$ ./a.out
No problems, no output.
Does this work:
$ gcc a.c -L/usr/local/ssl/lib -R/usr/local/ssl/lib -lssl -lcrypto
gcc: unrecognized option `-R/usr/local/ssl/lib'
$ ./a.out
--Tomki
win binary
A windows binary for 1.7 is present at http://space.tin.it/computer/hherold . Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
Re: win binary
The server seems to reset the connection when the source or binary is downloaded can you look into it Herold Heiko wrote: A windows binary for 1.7 is present at http://space.tin.it/computer/hherold . Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
Re: Please upgrade libtool in wget
Arkadiusz Miskiewicz [EMAIL PROTECTED] writes: Why you are trying to make things more difficult than they really are? Now I can't use new libtool.m4 (and other m4 macros) for wget without patching it. aclocal.m4 should be autogenerated to make life yeasier. I've never autogenerated aclocal.m4. In fact, this is the first Wget release that uses libtool at all. So in my eyes you are the one maing things difficult. So instead of quarreling, let's try to bear with each other and make Wget better. Please explain exactly how you autogenerate aclocal.m4 and why that's better than simply putting the stuff you need there! and also acconfig.h is missing (autoheader breaks on it). Don't use autoheader. The same here. If I want to add some patch to wget (ie ipv6 support) I need to fix it autoconfigure support... I don't know what autoconfigure is, and I definitely don't see what is the problem with adding ipv6 support. I am perfectly happy with Wget build system as it is, without the need for autoheader. If you don't explain how autoheader will make our lives better, I will probably not make changes to cater to its needs.
make install, wget.1, builddir != srcdir
`make install' fails to install the man page if the build directory is not the same as the source directory. It tries to find the man page in srcdir/doc/, but the man page gets built into builddir/doc/. Ryan
Re: Wget 1.7-pre1 available for testing
On 2001-06-02 20:50 +0200, Andre Majorel wrote: On 2001-06-02 17:30 +0200, Hrvoje Niksic wrote: - The empty LIBS problem remains (add -lsocket -lnsl). Do you have a config.log for this? Wget's configure tries hard to determine whether `-lsocket' and `-lnsl' are needed, and this seems to work on Solaris. Can you see why it fails on your machine? The problem seems so be in autoconf. From my attempts at compiling v1.6 on the same system : checking for gethostbyname in -lnsl... no checking for socket in -lsocket... no when in fact they are there. I don't have access to the machine until tuesday. I'll post the config.log then. Sorry. Tuesday is today. config.log for 1.6 and 1.7-pre1 attached. 1.7 is identical to 1.7-pre1. -- André Majorel Work: [EMAIL PROTECTED] Home: [EMAIL PROTECTED] http://www.teaser.fr/~amajorel/ config.log.gz config.log.gz
Re: Please upgrade libtool in wget
Russ Allbery [EMAIL PROTECTED] writes: Automake, on the other hand, I've never particularly liked and I think frequently just makes everything more complicated, not simpler. Several times I seriously considered switching to Automake, which might work well for a smaller project like Wget, but always got turned off by the incredibly huge and unreadable Makefiles it creates. The last time I have seen Makefiles that ugly was when `imake' still roamed the Earth. Automake is used by many to avoid the hassle of writing Makefiles (which is admittedly not easy, especially if you want them to be portable.) Hence many of today's projects have completely broken Automake-generated Makefiles because their authors never bothered to study `make'.
Re: Please upgrade libtool in wget
Hrvoje Niksic [EMAIL PROTECTED] writes: Several times I seriously considered switching to Automake, which might work well for a smaller project like Wget, but always got turned off by the incredibly huge and unreadable Makefiles it creates. The last time I have seen Makefiles that ugly was when `imake' still roamed the Earth. Automake is used by many to avoid the hassle of writing Makefiles (which is admittedly not easy, especially if you want them to be portable.) Hence many of today's projects have completely broken Automake-generated Makefiles because their authors never bothered to study `make'. Automake is attempting to solve a problem that I agree really does need to be solved, namely that make is rather baroque, portable make is about as difficult to figure out as portable shell, and make is really far too stupid (or general, if one wants to be more kind) to be a good software build tool since it doesn't natively know enough about how to build software. You really want to use a tool that has an innate concept of libraries, programs, installation rules, cleanup rules, and so forth so that you don't have to constantly re-invent the wheel. (And you really want a better built-in scripting language than portable Bourne shell, but that's another argument.) Unfortunately, Automake implements that higher-level build tool on top of make, and the automatically generated Makefiles look like the output of any other automatic code generator. It's the same reason why it's such a pain to use yacc; the resulting C code is essentially unreadable. And figuring out what's going on requires reading Makefiles and make -n output. In many respects, Automake represents the worst of both worlds, as a halfway house between a real software build system and a low-level dependency tracking tool (which is really what make is). I think I'd be more likely to jump all the way to one of the make replacements than to use Automake, not because Automake is necessarily a bad idea, but because of all the drawbacks of continuing to try to use portable make as a back-end. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: make install, wget.1, builddir != srcdir
Quoting Ryan Lovett ([EMAIL PROTECTED]): `make install' fails to install the man page if the build directory is not the same as the source directory. It tries to find the man page in srcdir/doc/, but the man page gets built into builddir/doc/. Thanks for the report. Apparently, also wget.info and message catalogues are either not build or not installed when build != src. I'm working on that. -- jan +-- Jan Prikryl| vr|vis center for virtual reality and visualisation [EMAIL PROTECTED] | http://www.vrvis.at +--
wget 1.7 configure errors
I said ./configure --with-ssl but the script said it couldn't find ssl libs. They're in the default /usr/local/ssl location. Looking at config.log, I see that gcc is upset, claiming that -rpath is an invalid option. That's right. It's a linker option so gcc should see -Wl,-rpath. If I make that change, then configure finds the ssl libs and the build proceeds. In the midst of trying to debug this, I tried using another gcc by saying CC=/usr/new/bin/gcc ./configure ... This syntax is described in every GNU INSTALL document I've ever seen. Your script does not honor it. Your script really should. Thanks. -- Mars 2001-06-05 20:00:57.973 UTC (JD 2452066.334004) X = -0.302186621, Y = -1.326263232, Z = -0.599968130 (au) X' = 0.014245527, Y' = -0.001339436, Z' = -0.000999401 (au/d)
gettext not found after libssl check failed
Hello,
subjects says it all:
When trying to compile with -lssl, an already reported bug in libssl
detection causes the library not to be found. However, it seems that
after the failure of the libssl test some things are seriously broken:
at least on my system the configure script will later not find
`gettext' ...
(1) ./configure --with-ssl=/usr
| 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
| checking for RSA_new in -lcrypto... no
| checking for SSL_new in -lssl... no
|
| WARNING: Failed to link with OpenSSL libraries in /usr/lib.
| Wget will be built without support for https://... URLs.
|
| checking whether NLS is requested... yes
| language catalogs: cs da de el es et fr gl hr it ja nl no pl pt_BR ru
| sk sl sv tr zh_TW
| checking for msgfmt... /usr/bin/msgfmt
| checking for xgettext... /usr/bin/xgettext
| checking for gmsgfmt... /usr/bin/msgfmt
| checking for locale.h... yes
| checking for libintl.h... yes
| checking for gettext... no
| checking for gettext in -lintl... no
| gettext not found; disabling NLS
| checking for makeinfo... makeinfo
(It seems that the SSL check forces `-rpath' and gcc does not like
it. Moreover, the SSL checks for -ldl and ingores it afterwards.)
(1) ./configure
| checking for socket in -lsocket... no
| checking for runtime libraries flag... -rpath
| checking whether NLS is requested... yes
| language catalogs: cs da de el es et fr gl hr it ja nl no pl pt_BR ru
| sk sl sv tr zh_TW
| checking for msgfmt... /usr/bin/msgfmt
| checking for xgettext... /usr/bin/xgettext
| checking for gmsgfmt... /usr/bin/msgfmt
| checking for locale.h... yes
| checking for libintl.h... yes
| checking for gettext... yes
| checking for makeinfo... makeinfo
The system is RedHat 6.2 CZ + numerous updates, compiler is a
prerelease of gcc 3.0 (gcc version 3.0 20010308 (prerelease))
I'm attaching a patch against current CVS version, which is almost 1.7
anyway. It's WORKSFORME, the SSL handling is certainly not optimal.
-- jan
+--
Jan Prikryl| vr|vis center for virtual reality and visualisation
[EMAIL PROTECTED] | http://www.vrvis.at
+--
Index: configure.in
===
RCS file: /pack/anoncvs/wget/configure.in,v
retrieving revision 1.17
diff -u -r1.17 configure.in
--- configure.in2001/05/28 22:02:47 1.17
+++ configure.in2001/06/05 21:27:09
@@ -205,14 +205,18 @@
AC_MSG_CHECKING(for runtime libraries flag)
case $host_os in
sol2 ) dash_r=-R ;;
- decosf* | linux* | irix*) dash_r=-rpath ;;
+ decosf* | irix*) dash_r=-rpath ;;
+ linux*) dash_r= ;;
*)
dash_r=
for try_dash_r in -R -R -rpath ; do
OLD_LDFLAGS=$LDFLAGS
LDFLAGS=${try_dash_r}/no/such/file-or-directory $LDFLAGS
+ dnl gcc seems to only produce a warning about nonexistent option
+ dnl `-R/no/such/file-or-directory' so the test comes thru
+ dnl (tested with gcc version 3.0 20010308 (prerelease))
AC_TRY_LINK(, , dash_r=$try_dash_r)
- LDFLAGS=$ODL_LDFLAGS
+ LDFLAGS=$OLD_LDFLAGS
test -n $dash_r break
done ;;
esac
@@ -235,9 +239,6 @@
ssl_all_roots=$with_ssl
fi
- OLD_LIBS=$LIBS
- OLD_LDFLAGS=$LDFLAGS
-
dnl Unfortunately, as of this writing (OpenSSL 0.9.6), the libcrypto
dnl shared library doesn't record its dependency on libdl, so we
dnl need to check for it ourselves so we won't fail to link due to a
@@ -245,6 +246,9 @@
dnl shl_load().
AC_CHECK_LIB(dl,dlopen)
AC_CHECK_LIB(dl,shl_load)
+
+ OLD_LIBS=$LIBS
+ OLD_LDFLAGS=$LDFLAGS
ssl_linked=no
Index: doc/Makefile.in
===
RCS file: /pack/anoncvs/wget/doc/Makefile.in,v
retrieving revision 1.13
diff -u -r1.13 Makefile.in
--- doc/Makefile.in 2001/04/12 12:25:22 1.13
+++ doc/Makefile.in 2001/06/05 21:27:09
@@ -66,7 +66,7 @@
sed s/@/@@/g $ $@
wget.info: $(SAMPLERCTEXI) $(srcdir)/wget.texi
- -$(MAKEINFO)
+ $(MAKEINFO) -I$(srcdir)
$(TEXI2POD): $(srcdir)/$(TEXI2POD).in
sed s,/usr/bin/perl,@PERL@, $ $@
@@ -115,7 +115,7 @@
# install man page, creating install directory if necessary
install.man: $(MAN)
$(top_srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/man$(manext)
- $(INSTALL_DATA) $(srcdir)/$(MAN) $(DESTDIR)$(mandir)/man$(manext)/$(MAN)
+ $(INSTALL_DATA) $(MAN) $(DESTDIR)$(mandir)/man$(manext)/$(MAN)
# install sample.wgetrc
install.wgetrc: $(srcdir)/sample.wgetrc
Re: wget 1.7 configure errors
Quoting tenthumbs ([EMAIL PROTECTED]): I said ./configure --with-ssl but the script said it couldn't find ssl libs. They're in the default /usr/local/ssl location. Looking at config.log, I see that gcc is upset, claiming that -rpath is an invalid option. That's right. It's a linker option so gcc should see -Wl,-rpath. If I make that change, then configure finds the ssl libs and the build proceeds. Yes, the SSL detection is broken on some systems. We are working on a fix. In the midst of trying to debug this, I tried using another gcc by saying CC=/usr/new/bin/gcc ./configure ... This syntax is described in every GNU INSTALL document I've ever seen. Your script does not honor it. Your script really should. Could you provide an example? On my machine, GCC is in /usr/local/bin by default (I'm using the GCC 3.0 development version which has some bugs, so I prevent to keep tow versions of the compiler). In this setup, `CC=/usr/bin/gcc ./configure ... ; make' will build wget with the old GCC 2.95.2 just fine. -- jan +-- Jan Prikryl| vr|vis center for virtual reality and visualisation [EMAIL PROTECTED] | http://www.vrvis.at +--
SEC: UNCLASS query strings
I'm using wget to mirror a site which is dynamically generated. The first page contains 1000s of hrefs looking like this. href=http://sitename/page.asp?page1; href=http://sitename/page.asp?page2; href=http://sitename/page.asp?page3; href=http://sitename/page.asp?page4; The mirroring process is fine. Wget puts the content into files like ./sitename/page.asp?page1 ./sitename/page.asp?page2 ./sitename/page.asp?page3 ./sitename/page.asp?page4 But the wget link-converted version of the first page - the one containing the 1000s of hrefs - contains relative links like this. href=sitename/page.asp?page1 href=sitename/page.asp?page2 href=sitename/page.asp?page3 href=sitename/page.asp?page4 I'd like them to be of the form href=sitename/page.asp%3Fpage1 href=sitename/page.asp%3Fpage2 href=sitename/page.asp%3Fpage3 href=sitename/page.asp%3Fpage4 Because then I could simply dump the mirror into an apache document root and browse the mirror locally. I gather that convert-links handles absolute-relative relative-absolute conversions but should it also handle URL-ENCODED-URL conversions?
Re: configuration, openssl
At 13:52 6/5/2001 +0200, you wrote:
Tomki [EMAIL PROTECTED] writes:
$ gcc a.c -L/usr/local/ssl/lib -lssl -lcrypto
$ ./a.out
No problems, no output.
Does this work:
$ gcc a.c -L/usr/local/ssl/lib -R/usr/local/ssl/lib -lssl -lcrypto
gcc: unrecognized option `-R/usr/local/ssl/lib'
How about:
$ gcc a.c -L/usr/local/ssl/lib -rpath /usr/local/ssl/lib -lssl -lcrypto
This gives:
gcc: unrecognized option `-rpath'
/usr/local/ssl/lib: file not recognized: Is a directory
collect2: ld returned 1 exit status
Also, could you mail the entire configure output here?
Sure, here it is:
./configure --with-ssl
creating cache ./config.cache
configuring for GNU Wget 1.7
checking host system type... i686-pc-linux-gnu
checking whether make sets ${MAKE}... yes
checking for a BSD compatible install... /usr/bin/ginstall -c
checking build system type... i686-pc-linux-gnu
checking for ranlib... ranlib
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking for object suffix... o
checking for executable suffix... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared
libraries... yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
updating cache ./config.cache
loading cache ./config.cache
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for gcc option to accept ANSI C...
checking for function prototypes... yes
checking for working const... yes
checking for inline... inline
checking for size_t... yes
checking for pid_t... yes
checking whether byte ordering is bigendian... no
checking size of long... 4
checking size of long long... 8
checking for string.h... yes
checking for stdarg.h... yes
checking for unistd.h... yes
checking for sys/time.h... yes
checking for utime.h... yes
checking for sys/utime.h... no
checking for sys/select.h... yes
checking for sys/utsname.h... yes
checking for pwd.h... yes
checking for signal.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking return type of signal handlers... void
checking for struct utimbuf... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking for strdup... yes
checking for strstr... yes
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for gettimeofday... yes
checking for mktime... yes
checking for strptime... yes
checking for strerror... yes
checking for snprintf... yes
checking for vsnprintf... yes
checking for select... yes
checking for signal... yes
checking for symlink... yes
checking for access... yes
checking for isatty... yes
checking for uname... yes
checking for gethostname... yes
checking for gethostbyname... yes
checking for socket in -lsocket... no
checking for runtime libraries flag... -rpath
checking for dlopen in -ldl... yes
checking for shl_load in -ldl... no
Looking for SSL libraries in default
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Looking for SSL libraries in /usr/local/ssl
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Looking for SSL libraries in /usr/local
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
Looking for SSL libraries in /opt
checking for RSA_new in -lcrypto... no
checking for SSL_new in -lssl... no
WARNING: Failed to link with OpenSSL libraries in /opt/lib.
Wget will be built without support for https://...
Re: Wget 1.7-pre1 available for testing
Quoting Andre Majorel ([EMAIL PROTECTED]):
Tuesday is today. config.log for 1.6 and 1.7-pre1 attached. 1.7
is identical to 1.7-pre1.
It seems that -lsocket is not found as it requires -lnsl for
linking. -lnsl is not detected as it does not contain
`gethostbyname()' function.
Would the attacheed patch to configure.in solve the problem? Please
not that the patch tries to correct somee other problems with
configure.in and these corrections may make it crash on your
system. The important change for you would be the
AC_CHECK_FUNCS(gethostname, [] ...) part.
-- jan
+--
Jan Prikryl| vr|vis center for virtual reality and visualisation
[EMAIL PROTECTED] | http://www.vrvis.at
+--
Index: configure.in
===
RCS file: /pack/anoncvs/wget/configure.in,v
retrieving revision 1.17
diff -u -r1.17 configure.in
--- configure.in2001/05/28 22:02:47 1.17
+++ configure.in2001/06/06 05:26:20
@@ -174,8 +174,12 @@
AC_CHECK_FUNCS(strdup strstr strcasecmp strncasecmp)
AC_CHECK_FUNCS(gettimeofday mktime strptime)
AC_CHECK_FUNCS(strerror snprintf vsnprintf select signal symlink access isatty)
-AC_CHECK_FUNCS(uname gethostname)
+AC_CHECK_FUNCS(uname)
+AC_CHECK_FUNCS(gethostname, [], [
+ AC_CHECK_LIB(nsl, gethostname)
+])
+
AC_CHECK_FUNCS(gethostbyname, [], [
AC_CHECK_LIB(nsl, gethostbyname)
])
@@ -205,14 +209,18 @@
AC_MSG_CHECKING(for runtime libraries flag)
case $host_os in
sol2 ) dash_r=-R ;;
- decosf* | linux* | irix*) dash_r=-rpath ;;
+ decosf* | irix*) dash_r=-rpath ;;
+ linux*) dash_r=-Wl,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
+ dnl gcc seems to only produce a warning about nonexistent option
+ dnl `-R/no/such/file-or-directory' so the test comes thru
+ dnl (tested with gcc version 3.0 20010308 (prerelease))
AC_TRY_LINK(, , dash_r=$try_dash_r)
- LDFLAGS=$ODL_LDFLAGS
+ LDFLAGS=$OLD_LDFLAGS
test -n $dash_r break
done ;;
esac
@@ -235,9 +243,6 @@
ssl_all_roots=$with_ssl
fi
- OLD_LIBS=$LIBS
- OLD_LDFLAGS=$LDFLAGS
-
dnl Unfortunately, as of this writing (OpenSSL 0.9.6), the libcrypto
dnl shared library doesn't record its dependency on libdl, so we
dnl need to check for it ourselves so we won't fail to link due to a
@@ -245,6 +250,9 @@
dnl shl_load().
AC_CHECK_LIB(dl,dlopen)
AC_CHECK_LIB(dl,shl_load)
+
+ OLD_LIBS=$LIBS
+ OLD_LDFLAGS=$LDFLAGS
ssl_linked=no
wget memory leak or expected operation
Hi, I'm currently using wget to mirror a rather extensive website. So far I've mirrored 10 gigs and counting. wget has been running for roughly 24 hours. My problem is the huge amount of memory wget has alloted to it. Since I have it converting links, I was wondering if maybe all the webpages I have been mirroring are being stored in memory for later conversion to relative links. This doesn't seem to be the case since some links have been converted. Unforunately a lot of the links on each page point to each other. It seems that wget may be downloading pages, converting them, and then re-downloading them and converting them again. My main concern is that my machine will run out of physical and swap memory before the mirroring is complete. Here's the output of top: 5874 jolan 24 44M 34M sleep select 581:40 10.99% wget And the command line with which I ran it with. jolan 5874 24.9 54.1 44980 35236 C5 RN+ Mon12AM 582:56.30 wget -t 0 -nH -k -m I'm using version 1.6. Thanks, Jolan
