[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version
MacPorts
noreply at macports.org
Sun Jun 2 12:06:15 UTC 2024
#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
More information about the macports-tickets
mailing list