From owner-freebsd-ports@FreeBSD.ORG Sun Dec 31 20:49:57 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2982916A403; Sun, 31 Dec 2006 20:49:57 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from mail.stovebolt.com (mail.stovebolt.com [66.221.101.249]) by mx1.freebsd.org (Postfix) with ESMTP id 02FF013C428; Sun, 31 Dec 2006 20:49:56 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-65-69-140-8.dsl.rcsntx.swbell.net [65.69.140.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.stovebolt.com (Postfix) with ESMTP id 8FF03114307; Sun, 31 Dec 2006 14:46:03 -0600 (CST) Date: Sun, 31 Dec 2006 14:49:54 -0600 From: Paul Schmehl To: Mike Durian , freebsd-ports@freebsd.org Message-ID: In-Reply-To: <200612311322.46830.durian@shadetreesoftware.com> References: <200612291040.29615.durian@shadetreesoftware.com> <45975BFB.2050604@FreeBSD.org> <200612311322.46830.durian@shadetreesoftware.com> X-Mailer: Mulberry/4.0.7b1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========CBE79525F840B92BDF24==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jeremy Chadwick , Doug Barton Subject: Re: www/libwww and SSL X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2006 20:49:57 -0000 --==========CBE79525F840B92BDF24========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On December 31, 2006 1:22:44 PM -0700 Mike Durian=20 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=20 rather than creating an option that must be selected before building. The Makefile already has: CONFIGURE_ARGS=3D --enable-shared --enable-static --with-zlib Why not just expand it to: CONFIGURE_ARGS=3D --enable-shared --enable-static --with-zlib --with-ssl ? Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========CBE79525F840B92BDF24==========--