Using a newer libcurl from "base"

[RJVB (René Bertin)]

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?