dependency on correct openssl?
Bill Cole
macportsusers-20171215 at billmail.scconsult.com
Sun Sep 8 20:16:14 UTC 2019
On 8 Sep 2019, at 15:05, Ken Cunningham wrote:
> All your points are fair. To be honest, the PR for the openssl upgrade
> was in the PR queue for six months, and it was perceived that all the
> relevant ports that would be affected had been identified and fixed...
> shows you how good we are are guessing that!
>
> MacPorts waited about a year more than other package managers to
> upgrade openssl, so we have lots of patches to use from elsewhere,
> thank goodness.
Yes, I've been living in fear of this day since the release of 1.1.1,
since I'm not optimistic enough to have been looking forward to it.
Since my use case is keeping a 1st-gen Core Duo iMac usable as a utility
server for world-facing services (mail, web, DNS) I was fully
anticipating a long rebuild cycle full of bumps. I expect that like me,
most MacPorts users don't have the mental bandwidth to keep an eye on
slow-moving big projects.
> That symlink might stop the rev-upgrade errors, but the symbols in the
> openssl libraries have changed, so you'll be wandering well into the
> land of "unpredictable behaviour" there.
The symlink(s) I made are solely for transition (literally only until
the terminal leaf ports like Postfix & Apache are rebuilt) but should
not have significant effects on how other ports that are able to use
v1.1.1 get built. However, that linkage *should* be entirely safe to
keep, because I did NOT replace the unversioned .dylib links which point
to the v1.1.1 libraries. The previous executables explicitly want
/opt/local/lib/lib{ssl,crypto}.1.0.0.dylib and that is the only problem
I'm trying to fix. Anything that *can* build with the v1.1.1 libraries
should be looking for the unversioned names.
--
Bill Cole
bill at scconsult.com or billcole at apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
More information about the macports-users
mailing list