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