[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:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------
Description changed by RJVB:

Old description:

> 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?

New description:

 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#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS