--On December 31, 2006 1:22:44 PM -0700 Mike Durian
<[EMAIL PROTECTED]> wrote:>
We've got the source, so we might be able to come up with an answer
that is a bit less conjectural. I encourage others to check my analysis.
When --with-ssl is defined the configure script expands some variables,
WWWSSL, SSLINC, LIBSSL, LWWWSSL, LIBWWWSSL and WWWSSLEX with non-empty
values. If --with-ssl is not defined, or set to no, these variables
are left empty. These variables are then set in every Makefile in
the libwww build. However, the variables are only used in the Makefiles
found in the SSL and Examples subdirectory (and children). I think
we can ignore the Examples case, unless someone is using one of the
examples as more than just an example.
The SSL subdirectory is included in every build, even if --with-ssl is
not defined. In the case where SSL is not defined, the libwwwssl library
does not get built, however the SSL related header files are still
installed.
When --with-ssl is defined, the libwwwssl library gets built and is
installed. As with the non-SSL case, the SSL header libraries are
also installed.
From this we see that the --with-ssl option only impacts the libwwwssl
library itself. It does not impact any of the other libwww libraries
(otherwise the SSL variables would have been used in other
Makefiles). In particular, --with-ssl only results in libwwwssl
libraries getting built and installed. SSL header files are always
installed.
Defining --with-ssl also impacts the libwww-config script which can
be used to generate a list of libraries needed when linking programs
that use libwww. In this case, -lwwwssl will be part of the library
list and any programs using libwww will also link against -lwwwssl.
But, if they aren't calling any functions found in -lwwwssl, it is
hard to see how this will make any impact.
So, adding --with-ssl will only impact other ports if part of their
configuration looks for the libwwwssl library and uses functions in
it, if found. That strikes me as a potential benefit to other ports,
as it might make possible expanded functionality. We know from PR #99863
that net/xmlrpc-c is one such port. From the PR, we know it will make
use of libwwwssl if it is configured using --with-www-ssl, which is
not an option in the BSD port Makefile.
That's just my $0.02.
Your two cents makes a great deal of sense. It also makes me wonder if it
would be better to simply build the port with the --with-ssl make arg
rather than creating an option that must be selected before building.
The Makefile already has:
CONFIGURE_ARGS= --enable-shared --enable-static --with-zlib
Why not just expand it to:
CONFIGURE_ARGS= --enable-shared --enable-static --with-zlib --with-ssl
?
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
