Re: OpenSSL checking rewritten
On 25 May 2001, Hrvoje Niksic wrote:
Ah yes, I understand. Due to SSL shared libs being placed in weird
places, they cannot always be located by the dynamic linker.
Even worse -- the dynamic linker doesn't find them even when they're
in the *standard* (default) places such as /usr/local/lib.
It isn't a standard place, unfortunately, at least according to the SVR4
ABI, which ELF dynamic linkers usually conform to.
Note that adding RPATH for a cross-compiled program would usually be
bogus anyway
Fully agreed. In fact, you will notice that the loop first tries to
be civil and play by the rules. If that fails, and it *does* fail on
Yep, I see and it's fine for me as I tend to place libs into /usr/lib.
Solaris, then it goes to look in special directories. Your
cross-compiling hack could simply convince AC_TRY_RUN that everything
is fine.
Since after studying the script I see that the AC_TRY_RUN test is just a
yes/no choice, this is actually the approach I've taken -- an AC_CACHE_VAL
invocation would simply be an overkill with no real benefit. It would be
nice to place the RPATH test under AC_CACHE_VAL, OTOH, but it's not a
necessity.
I'm wondering if the RPATH test is needed at all. Libtool knows how to
hardcode paths into libraries for a number of operating systems and
presents a consistent interface. Couldn't we use it?
Thanks. If you understand how the caching thing works, could you
please take a look at this... I am calling AC_CHECK_LIB in a loop,
but caching breaks that. So what I do is manually unset the caching
variables. This is dirty, but it works.
You would have to write an own enhanced version of AC_CHECK_LIB making
use of AC_TRY_LINK_FUNC or AC_TRY_LINK which are more general and do not
do caching themselves. Unsetting variables is probably the simplest way
in this case, though.
Is there a nicer way to temporarily disable caching?
None that I know of, even for autoconf 2.50.
Here are two patches I created working on wget over the weekend. I have
a few others available, as well: a libtool 1.4 update and fixes for
autoconf 2.50. I think the libtool update is worth considering now (1.3.5
has a few nasty cross-compiling bugs) and autoconf fixes would be a
post-1.7 item. Do you want to see these changes as well?
2001-05-28 Maciej W. Rozycki [EMAIL PROTECTED]
* configure.in: Don't fail the runtime linking test when
cross-compiling.
* configure.in: Use $host_os and not $opsys to denote the host OS.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
wget-1.7-dev-20010525-ssl-cross.patch
diff -up --recursive --new-file wget.macro/configure.in wget/configure.in
--- wget.macro/configure.in Fri May 25 00:23:22 2001
+++ wget/configure.in Sat May 26 17:10:02 2001
@@ -295,8 +295,10 @@ if test x$with_ssl != x -a x$with_ssl
AC_TRY_RUN([
char RSA_new();
char SSL_new();
-main(){return 0;}
-], AC_MSG_RESULT(yes), AC_MSG_RESULT(no); ssl_link_failure=yes)
+main(){return 0;}],
+ AC_MSG_RESULT(yes),
+ AC_MSG_RESULT(no); ssl_link_failure=yes,
+ AC_MSG_RESULT(cross))
fi
if test x$ssl_link_failure = xno; then
wget-1.7-dev-20010525-host_os.patch
diff -up --recursive --new-file wget.macro/configure.in wget/configure.in
--- wget.macro/configure.in Fri May 25 00:23:22 2001
+++ wget/configure.in Sat May 26 18:52:40 2001
@@ -203,7 +203,7 @@ dnl merely for the configure test below.
dnl performed by libtool. Wouldn't it be nice if libtool also
dnl provided querying that we need in configure?
AC_MSG_CHECKING(for runtime libraries flag)
-case $opsys in
+case $host_os in
sol2 ) dash_r=-R ;;
decosf* | linux* | irix*) dash_r=-rpath ;;
*)
Re: OpenSSL checking rewritten
Maciej W. Rozycki [EMAIL PROTECTED] writes: On 25 May 2001, Hrvoje Niksic wrote: Ah yes, I understand. Due to SSL shared libs being placed in weird places, they cannot always be located by the dynamic linker. Even worse -- the dynamic linker doesn't find them even when they're in the *standard* (default) places such as /usr/local/lib. It isn't a standard place, unfortunately, at least according to the SVR4 ABI, which ELF dynamic linkers usually conform to. That's why I put default in parentheses. The word standard has many meanings, only one of them being conforming to a written standard. Since after studying the script I see that the AC_TRY_RUN test is just a yes/no choice, this [ignoring AC_TRY_RUN if linking works] is actually the approach I've taken Also note that in the meantime I tried to implement the same thing. I'm wondering if the RPATH test is needed at all. Libtool knows how to hardcode paths into libraries for a number of operating systems and presents a consistent interface. Couldn't we use it? Libtool knows how to link the library, but it cannot tell you how it works its magic. That's a major fault in libtool, and since I was forced to implement the magic detection for configure anyway, I'm wondering why we're still using libtool at all. I am not taking out Libtool yet out of courtesy to Dan (who is currently too busy to participate), but I'm seriously considering it. Here are two patches I created working on wget over the weekend. I have a few others available, as well: a libtool 1.4 update and fixes for autoconf 2.50. I think the libtool update is worth considering now (1.3.5 has a few nasty cross-compiling bugs) and autoconf fixes would be a post-1.7 item. Do you want to see these changes as well? Definitely. I think we should stick to the libtool we have becaus,e as I said above, I'm seriously considering replacing it. The Autoconf 2.50 stuff is probably more appropriate for 1.8. 2001-05-28 Maciej W. Rozycki [EMAIL PROTECTED] * configure.in: Don't fail the runtime linking test when cross-compiling. This does not apply cleanly because I changed the code in the meantime. Could you check whether my changes work for you? * configure.in: Use $host_os and not $opsys to denote the host OS. I'll apply this; thanks.
Re: OpenSSL checking rewritten
On 28 May 2001, Hrvoje Niksic wrote:
I'm wondering if the RPATH test is needed at all. Libtool knows how to
hardcode paths into libraries for a number of operating systems and
presents a consistent interface. Couldn't we use it?
Libtool knows how to link the library, but it cannot tell you how it
works its magic. That's a major fault in libtool, and since I was
forced to implement the magic detection for configure anyway, I'm
wondering why we're still using libtool at all.
But do we need to know? The only problem is an inconsistency between the
configure script and the Makefile. The former invokes the linker
directly, while the latter using libtool. If we convinced the configure
script to invoke the linker using libtool, then we could avoid handcoding
RPATH support. The runtime check would remain intact, of course.
I am not taking out Libtool yet out of courtesy to Dan (who is
currently too busy to participate), but I'm seriously considering it.
Well, I remember the discussion on libtool that happened here some time
ago. ;-)
Definitely. I think we should stick to the libtool we have becaus,e
as I said above, I'm seriously considering replacing it.
I see.
The Autoconf 2.50 stuff is probably more appropriate for 1.8.
That's exactly what I stated -- but it doesn't hurt to be prepared. For
me it's desirable to have scripts prepared for 2.50 as software starts
requiring it and switching constantly between autoconf versions is
annoying.
* configure.in: Don't fail the runtime linking test when
cross-compiling.
This does not apply cleanly because I changed the code in the
meantime. Could you check whether my changes work for you?
It works, but the output is ugly (that's why my version outputs cross):
Looking for SSL libraries in default
checking for RSA_new in -lcrypto... yes
checking for SSL_new in -lssl... yes
checking whether runtime linking works... Compiling in support for SSL
in default
checking whether NLS is requested... yes
Don't worry of the quotes -- it's an autoconf 2.50 item after I disabled
the msg-quote (see below) patch temporarily.
Here are the patches. At least one of them does not apply cleanly
without my cross-compilation fix (so it surely won't apply to current
sources, either). But you should get the idea.
No ChangeLog entries at this time, but this is how I commented the
patches in my RPM spec file:
- do not use ac_given_srcdir in WGET_PROCESS_PO as required by
autoconf 2.50 (srcdir)
- call AC_AIX before AM_PROG_LIBTOOL as the latter invokes CC
(ac_aix)
- take m4 quote expansion into account (m4-quote)
- fixed weird message quoting (msg-quote)
I skipped the libtool patch as it's huge and it's just a new version of
libtool.m4 incorporated into aclocal.m4.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
wget-1.7-dev-20010525-ac_aix.patch
diff -up --recursive --new-file wget.macro/configure.in wget/configure.in
--- wget.macro/configure.in Fri May 25 00:23:22 2001
+++ wget/configure.in Sat May 26 15:53:35 2001
@@ -84,6 +84,11 @@ dnl
AC_PROG_INSTALL
dnl
+dnl Handle AIX. Should be called before any compiler invocation.
+dnl
+AC_AIX
+
+dnl
dnl Configure our included libtool and make sure it's regenerated when needed
dnl
AM_PROG_LIBTOOL
@@ -115,11 +120,6 @@ if test -n $auto_cflags; then
esac
fi
fi
-
-dnl
-dnl Handle AIX
-dnl
-AC_AIX
dnl
dnl In case of {cyg,gnu}win32. Should be a _target_ test.
wget-1.7-dev-20010525-m4-quote.patch
diff -up --recursive --new-file wget.macro/configure.in wget/configure.in
--- wget.macro/configure.in Fri May 25 00:23:22 2001
+++ wget/configure.in Sat May 26 17:19:38 2001
@@ -46,7 +46,7 @@ AC_ARG_WITH(socks,
[AC_DEFINE(HAVE_SOCKS)])
AC_ARG_WITH(ssl,
-[ --with-ssl[=SSL_ROOT] link with libssl [in SSL_ROOT/lib] for https: support])
+[[ --with-ssl[=SSL_ROOT] link with libssl [in SSL_ROOT/lib] for https: support]])
AC_ARG_ENABLE(opie,
[ --disable-opie disable support for opie or s/key FTP login],
wget-1.7-dev-20010525-msg-quote.patch
diff -up --recursive --new-file wget.macro/aclocal.m4 wget/aclocal.m4
--- wget.macro/aclocal.m4 Fri Apr 6 03:11:24 2001
+++ wget/aclocal.m4 Sat May 26 17:44:30 2001
@@ -102,7 +102,7 @@ AC_DEFUN(WGET_WITH_NLS,
dnl last moment.
if test x$HAVE_NLS = xyes; then
- AC_MSG_RESULT(language catalogs: $ALL_LINGUAS)
+ AC_MSG_RESULT_UNQUOTED([language catalogs: $ALL_LINGUAS])
AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,
[test -z `$ac_dir/$ac_word -h 21 | grep 'dv '`], msgfmt)
AM_PATH_PROG_WITH_TEST(XGETTEXT, xgettext,
diff -up --recursive --new-file wget.macro/configure.in wget/configure.in
--- wget.macro/configure.in Sat May 26 17:10:02 2001
+++ wget/configure.in Sat May 26 17:18:02 2001
@@ -202,7 +202,7 @@ dnl
Re: OpenSSL checking rewritten
Maciej W. Rozycki [EMAIL PROTECTED] writes: But do we need to know? We need to detect whether the library exists and is linkable, so that we can for instance set the appropriate preprocessor and makefile vraiebls. The only problem is an inconsistency between the configure script and the Makefile. The former invokes the linker directly, while the latter using libtool. Actually, the configure script is invoking *compiler*, not the linker directly (that is bad juju). Libtool, on the other hand, *is* invoking linker directly. But I'm digressing. If we convinced the configure script to invoke the linker using libtool, then we could avoid handcoding RPATH support. The runtime check would remain intact, of course. I see your point. Maybe someone should look into whether that's possible or feasible. I will not be the one because I don't consider libtool worth my time at this point. Definitely. I think we should stick to the libtool we have becaus,e as I said above, I'm seriously considering replacing it. I see. But on the other hand if someone convinces me that Configure can effectively use libtool and removes the -R detection and stuff, it will be a serious argument *for* libtool, if you see where I'm going. It works, but the output is ugly (that's why my version outputs cross): I see. I'll introduce the coross thing to fix the output, then. Here are the patches. At least one of them does not apply cleanly without my cross-compilation fix (so it surely won't apply to current sources, either). But you should get the idea. Thanks a lot for the patches. Could you clarify: are these patches meant for Autoconf 2.50 only, or will they work with the older Autoconf versions too? If it's the former, I'll look into them in a week or so when I integrate them to 1.8. No ChangeLog entries at this time, but this is how I commented the patches in my RPM spec file: nagChangeLog entries are good!/nag :-)
Re: OpenSSL checking rewritten
On 28 May 2001, Hrvoje Niksic wrote:
But do we need to know?
We need to detect whether the library exists and is linkable, so that
we can for instance set the appropriate preprocessor and makefile
vraiebls.
Yes, we do, but that's independent from RPATH handling. I mean the Try
to autodetect runtime library flag[...] script fragment. If we convinced
AC_CHECK_LIB to invoke `libtool --mode=link ${LD}' instead of just `${LD}'
we could get rid of it. It might be easier with autoconf 2.50 -- people
are working on improving autoconf/automake/libtool cooperation so newer
versions are more likely to be more flexible.
A post-1.7 issue, anyway -- what is now works good for the cases it knows
of.
The only problem is an inconsistency between the configure script
and the Makefile. The former invokes the linker directly, while the
latter using libtool.
Actually, the configure script is invoking *compiler*, not the linker
Of course I mean inovoking the linker via a compiler driver i.e.
`${LD}', as opposed to `libtool --mode=link ${LD}' -- I just used a
shortcut (I shouldn't have, I suppose -- too many people consider invoking
`ld' even if they have no good reason).
directly (that is bad juju). Libtool, on the other hand, *is*
invoking linker directly. But I'm digressing.
That's an internal implementation detail. I think we shouldn't care as
long as it works. Note that invoking ${LD} may have side effects (e.g.
with gcc ld is called indirectly via collect2), so libtool may actually
know what it is doing.
I see your point. Maybe someone should look into whether that's
possible or feasible. I will not be the one because I don't consider
libtool worth my time at this point.
As I mostly use linux-gnu systems, I don't really care, either, but I
like things to be done cleanly and this is a generic autoconf vs
libtool problem, so I'm adding it to my to-do list, in case I have some
time to spare.
But on the other hand if someone convinces me that Configure can
effectively use libtool and removes the -R detection and stuff, it
will be a serious argument *for* libtool, if you see where I'm going.
Sure thing. One of major libtool's goals is to simplify the life of
maintainers with respect to weird systems.
Thanks a lot for the patches. Could you clarify: are these patches
meant for Autoconf 2.50 only, or will they work with the older
Autoconf versions too?
They mostly work for 2.13 (except from the AC_MSG_RESULT_UNQUOTED
invocation) but the AIX patch issues a warning when running autoconf and
the quoting patches add superfluous brackets in the `./configure --help'
output. Can't comment the gettext patch -- that's weird in the first
place, but it just implements what autoconf's ChangeLog suggests (why
can't you use AM_GNU_GETTEXT so we have a single place to fix, anyway?).
nagChangeLog entries are good!/nag
OK, these should fit, more or less. Modify as needed when you look into
the patches:
2001-05-28 Maciej W. Rozycki [EMAIL PROTECTED]
* configure.in: Move AC_AIX before AM_PROG_LIBTOOL.
* configure.in: Add second level of brackets in AC_ARG_WITH for
ssl.
* configure.in: Replace double quotes with brackets for proper m4
quoting in AC_MSG_CHECKING and AC_MSG_RESULT throughout.
aclocal.m4 (WGET_WITH_NLS): Likewise. Use AC_MSG_RESULT_UNQUOTED
and quote $ALL_LINGUAS for a single-line output.
* aclocal.m4 (WGET_PROCESS_PO): Don't use $ac_given_srcdir as its
undefined for autoconf 2.50. Use $srcdir as is.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
Re: OpenSSL checking rewritten
Maciej W. Rozycki [EMAIL PROTECTED] writes:
directly (that is bad juju). Libtool, on the other hand, *is*
invoking linker directly. But I'm digressing.
That's an internal implementation detail. I think we shouldn't care as
long as it works. Note that invoking ${LD} may have side effects (e.g.
with gcc ld is called indirectly via collect2), so libtool may actually
know what it is doing.
There's a bunch of reasons why Libtool is wrong in what it does, but
they're not worth discussing here. As I said, it's just a digression.
Thanks a lot for the patches. Could you clarify: are these patches
meant for Autoconf 2.50 only, or will they work with the older
Autoconf versions too?
They mostly work for 2.13 (except from the AC_MSG_RESULT_UNQUOTED
invocation) but the AIX patch issues a warning when running autoconf and
the quoting patches add superfluous brackets in the `./configure --help'
output.
So most of them are not for 2.13? Hmm, I'll have to investigate that
on my own, I guess.
Can't comment the gettext patch -- that's weird in the first place,
but it just implements what autoconf's ChangeLog suggests (why can't
you use AM_GNU_GETTEXT so we have a single place to fix, anyway?).
Last time I checked, AM_GNU_GETTEXT expected you to bundle gettext
with your program. IMHO unacceptable.
Re: OpenSSL checking rewritten
On 28 May 2001, Hrvoje Niksic wrote: So most of them are not for 2.13? Hmm, I'll have to investigate that on my own, I guess. That's actually good news the changes are basically cosmetic -- no need to rewrite scripts heavily, unlike for some other programs. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: OpenSSL checking rewritten
Maciej W. Rozycki [EMAIL PROTECTED] writes:
I mean the Try to autodetect runtime library flag[...] script
fragment. If we convinced AC_CHECK_LIB to invoke `libtool
--mode=link ${LD}' instead of just `${LD}' we could get rid of it.
I was reminded why this won't work. Because libtool simply *doesn't*
handle the gcc-inserts-dash-L/usr/local/lib-but-not-dash-R problem!
That's what made me change configure in the first place.
Perhaps this works better with Libtool 1.4. That has to be
investigated, but after 1.7.
http file creation
I am having a problem doing a recursive get from a web page. The issue is that the link it downloads happens to have a date in it. It is obviously formated like 5/28/01. The problem is that wget saves the file out and the shell assumes that the / in the date is a new directory. Now I've got several directories where I should have files and the index page is unable to find the correct file because it has been converted to a series of directories. I assume the fix would be to make sure that the write function does a literal creation of the filename or somehow convert / characters with something else in both the file creation and the downloaded referencing page. Thanks much
