[MacPorts] #70127: Using a newer libcurl from "base"

[MacPorts]

#70127: Using a newer libcurl from "base"
-------------------------+--------------------
 Reporter:  RJVB         |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  base         |    Version:
 Keywords:               |       Port:
-------------------------+--------------------
 MacPorts "base" links against the system libcurl for understandable
 reasons but this leads to failures on older OS versions when fetching
 information over secure connections.

 I seem to recall we already discussed this a while back, but can't seem to
 find traces of it.

 I put a copy of the actual libcurl binary from `port:curl` (built
 `+gnutls` so the system libcrypto can't clash with the one from MacPorts)
 in `$prefix/libexec/macports/lib/pextlib1.0/` and run `install_name_tool`
 (or `patchelf`) on the pextlib library so it will load that copy.

 So far this has not led to problems for me but it's not much more than a
 local hack. `port:curl` has a few too many dependencies and it doesn't
 seem trivial at all to build it against static lib versions of all those
 dependencies, creating a standalone libcurl which could then be provided
 for download from macports.org .

 But libcurl is only called from pextlibs `curl.c` as far as I've seen, and
 my hack has shown that a pextlib built with quite "old" curl headers from
 the system works fine with a newer libcurl.
 That should mean that pextlib ought to be able to `dlopen` libcurl from a
 number of supported locations (including for instance
 $prefix/libexec/curl`) and load the required symbols at runtime using
 `dlsym`. The libcurl at that special location could then be provided by a
 properly groomed port, probably even a subport of `port:curl`.

 Using `dlopen` instead of using an `@rpath` style dependency is more work
 but should provide more resilience against the special libcurl failing to
 load because of a missing dependency. If however dyld will in that case
 just load the next libcurl in the rpath then that solution would be less
 work, and could even be handled in a post-install script.

 Thoughts? Am I overlooking something obvious?

-- 
Ticket URL: <https://trac.macports.org/ticket/70127>
MacPorts <https://www.macports.org/>
Ports system for macOS