fixing curl fetches on older MacPorts versions by using MacPorts' self-installed version of curl

Ken Cunningham ken.cunningham.webuse at gmail.com
Wed Nov 25 21:06:27 UTC 2020



> On Nov 25, 2020, at 11:19 AM, Joshua Root <jmr at macports.org> wrote:
> 
> On 2020-11-26 06:08 , Ken Cunningham wrote:
>> <https://github.com/macports/macports-base/blob/938d8528b896f15dc10c21a208b795f78acac127/src/port1.0/portfetch.tcl#L565>
>> 
>> where fetch just calls “curl” — but what is that — just the first curl in the PATH? If so, it should work as I describe and use the newer curl if it exists, and it doesn’t, so there must be more to it that just that.
> 
> It's a Tcl command provided by pextlib. PATH has no effect on where
> commands are found in Tcl code unless you're using exec or system.
> <https://github.com/macports/macports-base/blob/master/src/pextlib1.0/Pextlib.c#L1096>
> 
> - Josh

Right, thanks. I think I see how it works now. We use this to make up our own MacPorts curl command using the curl library:

<https://github.com/macports/macports-base/blob/master/src/pextlib1.0/curl.c <https://github.com/macports/macports-base/blob/master/src/pextlib1.0/curl.c>>

Well — to make this work we’d either have to force the newer libcurl from ${prefix}/lib using DYLD_LIBRARY_PATH or interposing it or some other idea, or we’d have to something in the curl.c code to try to dlopen the one in ${prefix} and use it preferentially somehow, if it exists.

I will see if I can make heads or tails out of how to do either of those.

Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201125/f720e776/attachment.htm>


More information about the macports-dev mailing list