[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:               |
--------------------------+--------------------

Comment (by RJVB):

 Replying to [comment:4 kencu]:
 > If that is actually not necessary, and the libcurl abi has not changed
 in years and the calls and structures remain the exact same over all the
 years —- that would be…unexpected…. but would make things much simpler.

 For OS X 10.9 my memory tells me I saw "2.7.2" in the system curl-config
 yesterday; I think that rather means the system has version 7.2.x . My
 Linux rig has system libcurl 7.35.0 . Both systems have `port:curl`
 currently at 8.7.1 . I have done the hack I described on both, making it
 `Pextlib.so` link to a copy of `libcurl` (`+gnutls` as stated) installed
 in the same directory. A bit more involved to achieve on Linux but we
 don't need to get into that here.

 And as said, I have yet to notice any problems.

 Which isn't in fact unexpected at all if you look at the SOVERSION, which
 has been `4` since those 2.7 series AFAICT. In fact, the DebUntu packaging
 suggests that even applications built against SOVERSION 3 can run against
 SOVERSION 4; the library's runtime package is called `libcurl3` (or
 `libcurl3-gnutls`) and installs `libcurl.so.4.3.0` which gets exposed as
 both `libcurl.so.4` (as you'd expect) but also as `libcurl.so.3` . I
 actually had to double-check if that wasn't a hack I made, but no, it's
 really packaged like that. I think we can trust the people behind Debian
 (and the commercial entity behind Ubuntu) to have checked the validity of
 this thoroughly. MacPorts probably only uses a subset of libcurl
 functionality, too.

 As usual one should expect to be able to build against one version and
 then run against an older version. But that should never be the case here.

 FWIW, I been using `port:MacPorts-devel` for years now to
 build+destroot+(d)pkg my MacPorts installs (sorry but not sorry to
 whomever it was who told me once that "MacPorts is not a build system" ;)
 ). That means I have a certain preference to keep the number of
 assumptions about local modifications/additions to system software as
 small as possible.
 (It also means I was quite annoyed I had to restore and maintain the
 `dpkg` functionality but that's yet another issue.)

 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 :)

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