[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:133 noloader]:

 > OpenSSL is easy to build because it has almost no dependencies.

 True, contrary to GnuTLS...


 > The bootstrapped version of cURL or Wget uses static linking. You don't
 have to worry about API and ABI compatibility because nothing gets loaded
 at runtime.

 This would be true if "base" invoked the actual external curl command. It
 doesn't; instead Pextlib provides a Tcl command `curl` (see my attached
 patch). I still have a patch for `portfetch.tcl` which adds a fallback to
 doing that if the built-in command fails (without crashing). That worked
 for fetching distfiles but not for other things like `port livecheck`.
 Hence my post-hoc relinking of Pextlib, and hence the rabbit hole of
 OpenSSL ABI clashing that I already went down once when `port` started
 crashing on me.

 Re: dependencies: libressl has *no* dependencies at all. It also builds a
 lot faster than OpenSSL and is almost half the size, I just noticed. Plus,
 curl has detection of LibreSSL vs. OpenSSL in place when configuring the
 SSL backend.

 I just added this to `porrt:libressl`:
 {{{
 subport ${name}-co {
     description-prepend Co-installable
     long_description-append \nThis port is co-installable with
 port:openssl

     # should libressl and libressl-co conflict with each other? I don't
 see
     # a good reason given that the purpose of libressl-co is to allow
 other
     # ports to use LibreSSL regardless of what SSL variant other ports use
     # by default.
     conflicts-replace \
                     openssl \
                     libressl
     set thePrefix   ${prefix}/libexec/libressl
     configure.pre_args \
                     --prefix=${thePrefix}
     # avoid having a conflicts_build with port:openssl:
     configure.ldflags-delete \
                     -L${prefix}/lib
     configure.ldflags-append \
                     -Wl,-rpath,${thePrefix}/lib
     post-destroot {
         foreach p [glob ${destroot}${thePrefix}/lib/pkgconfig/*.pc] {
             # we really should replace the -L/here -lfoo with
 /here/libfoo.? so
             # clever compilers/linkers cannot reorder the arguments and we
 can
             # build this port without build conflict on openssl(-dev)!!
             reinplace -q "s|Libs: |Libs: -Wl,-rpath,${thePrefix}/lib |g"
 ${p}
         }
     }
 }
 }}}

 and this variant to my `port:curl`(@8.7.1):
 {{{
     variant libre requires ssl description {Use the LibreSSL instead of
 OpenSSL} {
         PortGroup               conflicts_build 1.0
         depends_lib-replace     path:lib/libssl.dylib:openssl \
                                 port:libressl-co
         configure.pkg_config_path-prepend \
                                 ${prefix}/libexec/libressl/lib/pkgconfig
         depends_build-delete    port:pkgconfig
         depends_build-append    port:pkgconfig
         conflicts_build         openssl-dev
         configure.ldflags-delete \
                                 -L${prefix}/lib
     }
 }}}

 Next step is to test if this gives a fully functional Pextlib without
 libcrypto ABI clashes.

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