RE: OpenSSL checking rewritten
Me too- how 2 unsubscribe? -Original Message- From: Vundas Sabaka Deneg Net [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 8:58 AM To: Maciej W. Rozycki; Hrvoje Niksic Cc: Wget List Subject: Re: OpenSSL checking rewritten how 2 unsubscribe? This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.
Re: OpenSSL checking rewritten
On 28 May 2001, Hrvoje Niksic wrote: But still, let me see if I got it right: - without the changes, Wget won't compile with Autoconf 2.50 It mostly will, except of a failure in the po subdirectory due to a missing Makefile. - with the changes, Wget won't compile with Autoconf 2.13. It will, at least in place. Haven't checked building in a separate tree, which might fail in po again. This means that the changes should REQUIRE version 2.50, except that I don't have it on my system! Why did they have to change Autoconf incompatibly??? Autoconf seems to be mostly compatible, except of a few obscure cases, which were mostly a result of looking at a previous implementation instead of a documented behaviour. In wget's case, the problem is a reference to ac_given_srcdir (FYI, gettext 0.10.38 suffers from the same problem). I think you could discuss any compatibility problems on the autoconf's mailing list. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
Re: OpenSSL checking rewritten
On 29 May 2001, Hrvoje Niksic wrote: Aha, so you mean it's safe to use -R... as a *libtool* flag, which libtool will interpret as necessary. Exactly. Try `libtool --mode=link --help' for all options libtool recognizes in the link mode. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+
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.
Re: OpenSSL checking rewritten
On 25 May 2001, Hrvoje Niksic wrote: Dan is busy with other things, so I'm jumping in with this to make the release possible. I followed the outline of Dan's strategy, except that I didn't want to link with the library directly. The code should correctly detect the following cases: Would it be possible to add a default to AC_TRY_RUN or place it under AC_CACHE_VAL so that cross-compiling works? Wget 1.6 can be cross-compiled fine; due to this patch, the CVS version cannot anymore. I'd vote for AC_CACHE_VAL for consistency. What is the AC_TRY_RUN test needed for at all, BTW? Can't it be replaced with an AC_TRY_LINK or an AC_TRY_LINK_FUNC one? The function called in AC_TRY_RUN doesn't do anything catchable by the configure script at all -- it does never fail. 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:
Would it be possible to add a default to AC_TRY_RUN or place it under
AC_CACHE_VAL so that cross-compiling works?
I have no idea what AC_CACHE_VAL is. I know that AC_TRY_RUN can be
given a parameter that tells it what to do when cross-compiling. I've
never cross-compiled an Autoconf-based program, so I don't know what
should go there.
BTW, are you really cross-compiling Wget, or are you complaining out
of principle?
What is the AC_TRY_RUN test needed for at all, BTW? Can't it be
replaced with an AC_TRY_LINK or an AC_TRY_LINK_FUNC one?
It sounds strange, but AC_TRY_RUN really is needed. Please believe me
that I would have avoided it at all costs if I could.
The function called in AC_TRY_RUN doesn't do anything catchable by
the configure script at all -- it does never fail.
The function doesn't fail, but the program can and does fail when
either libcrypto or libssl are not resolved by the runtime linker.
The situation I'm trying to avoid is where a seemingly correct Wget
executable is built, but it fails when you try to run it. This
happens very often when compiling with Gcc on Solaris because Gcc
links with -L/usr/local/lib by default, but doesn't add the
corresponding -R. That's why, on my system, this happens:
$ echo 'main(){}' a.c
$ gcc a.c -lcrypto
$ ./a.out
ld.so.1: ./a.out: fatal: libcrypto.so.0: open failed: No such file or directory
zsh: killed ./a.out
So much for never fails. On the other hand:
$ echo 'main(){}' a.c
$ gcc a.c -R/usr/local/lib -lcrypto
$ ./a.out
$
The only way to avoid the above breakage is to try to run the program
and see if it works. I'll add comments that explain why AC_TRY_RUN is
needed.
