[MacPorts] #64189: legacy-support-devel @20211111: "port" wedged after deactivation
MacPorts
noreply at macports.org
Mon Dec 13 09:43:27 UTC 2021
#64189: legacy-support-devel @20211111: "port" wedged after deactivation
-----------------------------------+--------------------------
Reporter: evanmiller | Owner: cjones051073
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.7.1
Resolution: duplicate | Keywords: tiger
Port: legacy-support-devel |
-----------------------------------+--------------------------
Comment (by cjones051073):
Replying to [comment:10 kencu]:
> I wonder if it would be most efficient to find a way to use the
/opt/local port installation to build a bare-bones curl that will install
completely separately in /opt/curl or some such -- kind of the way we
build libc++ with macports in /opt/local, but thereafter it is installed
and untouched by macports in /usr/lib, even if libcxx is deactivated or
installed.
>
> Then at least a whole pile of waste (compilers, port trees, useless
installs of perl and python, etc) could all be avoided.
>
> And macports would not "ship" a bundled curl, which seems to get people
concerned.
>
> Might just be a bit of work with copying some stuff and
install_name_tool, if we were really lucky, kinda like what I did stealing
libc++ from clang-11 to make the macports-libcxx port.
I think that would get messy fast. you would have to copy quite a chain of
dynamic libraries and fix them all up with install_name_tool. You would
also have to copy over the headers for curl (at least) in order to build
against that set of dylib, plus maybe who knows what else for the over
deps.
personally I think it much easier to run the installation in a separate
bootstrap area, and then just run 'sudo port reclaim' to remove all the
build dependencies, etc., after the fact.
--
Ticket URL: <https://trac.macports.org/ticket/64189#comment:14>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list