[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version

[MacPorts]

#51516: MacPorts should use a bundled copy of a newer libcurl and SSL library
rather than the OS X version
--------------------------+--------------------------------
  Reporter:  ryandesign   |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:  MacPorts Future
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by RJVB):

 Replying to [comment:109 kencu]:
 > In that latter message are the issues outlining the problem with just
 simply "switching" the libcurl versions, and indicating how base would
 have to be rebuilt, at least in part, against the newer libcurl and the
 older libcurl. I won't try to re-explain it all as it is well outlined in
 that message.

 But as you indicated in the other thread, if practise shows otherwise,
 maybe the approach can be reconsidered and/or simply tested. And in
 practise it does seem to be the case that you can "just" change libcurl
 for a ''newer'' version, as long as it's known or proven to be backwards
 ABI-compatible. As stated in the other ticket, I have yet to find a
 version that is *not*, even w.r.t. to "ancient" 2.7.x versions.

 I really don't see why Pextlib would be any different from any of the
 other curl dependents which AFAICT do NOT get revbumped at every curl
 upgrade (except p5-www-curl for a reason I cannot determine).

 And just to be clear, I'm not suggesting to load
 `${prefix}/lib/libcurl.?`. It should be loaded from a "hidden" location,
 installed there in (semi)-permanent fashion and be a variant that does not
 use OpenSSL (because Pextlib links to the system libcrypto which can clash
 with the one in MacPorts). It could be installed as a special port
 (standalone or subport of `port:curl`) which installs only the actual
 library or installed/updated from a `port-activate` block of one of the
 suitable variants of `port:curl` itself. A special, dedicated port would
 make it easier to push updates of course, if and when it's justified to do
 so given how "base" uses curl.

 Replying to [comment:5 RJVB]:
 > Anyway, how much work and how tricky would it be to make `curl.c` load
 whatever it needs from libcurl dynamically? I'm not against digging into
 that but if there's already idea of what I'd be getting into I also not
 against knowing that beforehand :)

 TBH, I find that a quite satisfying kind of lowlevel tinkering. More so if
 it's not just for me of course.

 I've done similar things before, also in such a way that the actual
 behaviour can be determine at build time like with Qt's use of OpenSSL
 (i.e. linked-in or loaded dynamically). Looking at `curl.c` I'd be tempted
 to do the loading in lazy fashion, i.e. try to load a libcurl and then
 load `curl_global_init()` from it in `CurlInit()`, and load each symbol
 when needed, in the function that needs it (and probably move them all to
 `CurlInit()` or a dedicated function in a 2nd step).

-- 
Ticket URL: <https://trac.macports.org/ticket/51516#comment:111>
MacPorts <https://www.macports.org/>
Ports system for macOS