www/libwww and SSL

Mike Durian durian at shadetreesoftware.com
Sun Dec 31 12:22:50 PST 2006


On Sunday 31 December 2006 11:18, Paul Schmehl wrote:
> --On December 30, 2006 10:43:07 PM -0800 Doug Barton <dougb at FreeBSD.org>
>
> wrote:
> > Paul Schmehl wrote:
> >> What I want isn't really relevant.  I'm simply suggesting that updating
> >> the port to include an OPTION for with_ssl seems unnecessary *unless*
> >> someone is going to port sipX.  Have you looked at sipX?  Porting it
> >> would not be simple, and I wonder how much demand there would be.  In
> >> any case, *unless* sipX gets ported, it doesn't make sense to me to
> >> update www/libwww simply to enable an option no one has asked for until
> >> now.
> >
> > OTOH, what harm does it cause?
>
> That depends on how the port is patched.  If with_ssl is included in every
> build, it's hard to say.  There may be many unintended consequences.  If
> with_ssl is included as an OPTION, then when the port is built it will
> require someone to be at the console (or an entry in /etc/make.conf.)

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.

mike



More information about the freebsd-ports mailing list