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

[Clemens Lang]

Hi,

On Wed, Nov 25, 2020 at 01:06:27PM -0800, Ken Cunningham wrote:
> 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.

All of these solutions rely on the assumption that the copy of libcurl
you dlopen(3), interpose, inject using DYLD_INSERT_LIBRARIES, load using
DYLD_LIBRARY_PATH or execute in some other fashion is binary-compatible
with the copy Pextlib1.0 was originally built against.

Additionally, some of the code in curl.c depends on the version of
libcurl it was compiled against, see occurrences of LIBCURL_VERSION_NUM
and CURLOPT_ACCEPT_ENCODING.

I'm not sure it's feasible to get this right.

You could, however, try to write a port that provides a compatible
re-implementation of the Tcl curl command against MacPorts libcurl that
gets loaded after Pextlib.dylib is loaded. This could be as simple as

- recompiling the current state of curl.c against MacPorts libcurl
- adding some of the code currently found in Pextlib_Init from pextlib.c
  to register that in the Tcl interpreter (and potentially some
  additional code to move or overwrite a previously existing
  implementation)
- compile that into a library and install it in
  $prefix/libexec/macports/lib/pextlib1.0
- modify $prefix/libexec/macports/lib/pextlib1.0/pkgIndex.tcl to load
  that file after Pextlib.dylib if it exists.

Note that pkgIndex.tcl is currently auto-generated. However, something
along the lines of the following block could potentially work:

package ifneeded Pextlib 1.0 {
	load [file join $dir Pextlib.dylib]
	if {[file exists $dir PextlibOverride.dylib]} {
		load [file join $dir PextlibOverride.dylib]
	}
}

This should probably be extended to deal with situations where the
library does not load (e.g. because it's an old, no longer supported
architecture, its dependent copy of libcurl.dylib is currently missing
or has been uprgaded to a newer ABI, etc.).

Note that any crash in that library will lead to users being unable to
deactivate the port that likely installed that library, too.

Happy hacking!
-- 
Clemens