Sprinkling WITH_OPENSSL_BASE in ports, ratbox build failure.
dewayne.geraghty at heuristicsystems.com.au
Thu Jan 29 08:27:00 UTC 2015
On 28/01/2015 6:42 PM, Matthew Seaman wrote:
> On 2015/01/28 05:57, Dewayne Geraghty wrote:
>> ratbox generated an unusual error message today, via portmaster on a
>> 10.1Stable, amd64 system
>> However commenting out the recently inserted
>> from the Makefile enables the build to complete and uses the correct
>> crypto and ssl libraries. Shouldn't it be an option base or port? Or
>> is the openssl port going to go away?
> More like the other way around: ports will use the openssl version from
> ports exclusively, and the version in the base system will move into a
> private location. (This is my understanding of current thinking, but I
> make no guarantee that it is what does eventually get implemented.)
> The ircd-ratbox port doesn't appear to be doing anything unusual with
> respect to openssl support that I can see from a quick inspection of the
> port Makefile.
> If you've just added 'WITH_OPENSSL_BASE' to your make.conf, then (a) you
> potentially need to recompile many ports which depend on openssl so you
> don't end up with mixed linkage against both ports and base, and (b)
> some ports require the ports version of openssl because they depend on
> functionality only in the newer version available from ports.
> Personally, I prefer 'WITH_OPENSSL_PORT=yes' It's meant I have been
> able to turn off SSLv2 and SSLv3 everywhere pretty simply (no more
Thank-you for taking the time to review and advise.
It turned out that
was inserted into the irc-ratbox/Makefile some time about but only
recently took effect due to the addition of USE= openssl (#1) which
triggered the application of openssl from base [Thanks to John Marshall
for explaining the sequence, offline]. I do have WITH_OPENSSL_PORT in
my old ports.conf so when I removed the
from the Makefile everything went as expected. Since our email exchange
the Makefile has been modified and the world is a happier place for it ;)
Kind regards, Dewayne.
PS I still use WITH/WITHOUT options in ports.conf as I have a filter
that does the correct ..._SET/.._UNSET work. Done at a time during high
Reference: #1 I suspect that this had something to do with it
More information about the freebsd-ports