#52414: libarchive port fails problem with -pthread argument to clang -------------------------+-------------------- Reporter: JustinCB@… | Owner: toby@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: libarchive | -------------------------+-------------------- Comment (by JustinCB@…):
Installing MacPorts somewhere under $HOME is not uncommon. Using $HOME directly as the prefix and overriding CPATH and LIBRARY_PATH is. You mean installing the port commands under $HOME is not uncommon, but $HOME as the prefix is? CPATH and LIBRARY_PATH are set to (prefix)/include and (prefix)/lib respectively.
You can't use libraries you compiled yourself in macports, but you can use tools that you either compiled yourself or are included with the system(like CMake), and I was trying to build something that required CMake. It can use the CMake I compiled.
You can technically override MacPorts’ toolchain, yes, but we do not support doing so and are not obligated to accommodate such configurations. Macports defaults to using toolchains that already exist, even if they aren't Macports toolchains.
I don't think this bug is in the libarchive build system, it is a bug in libtool that causes it to automatically link against the system libraries, even if you told it explicitly that you want it to link to different libraries.
There very well might be a bug in libtool, but it’s not quite what you are describing. Anyone using MacPorts in the standard fashion gets a libarchive that is //not// linked to the system libraries. {{{ % otool -L /opt/local/lib/libarchive.13.dylib /opt/local/lib/libarchive.13.dylib: /opt/local/lib/libarchive.13.dylib (compatibility version 16.0.0, current version 16.1.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0) /opt/local/lib/liblzo2.2.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/local/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.2.0) /opt/local/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.6) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) }}} I think that the bug is that if it tries to link to a library that is not in a "standard" path, it will replace it with one that is in a "standard" path if one exists.
-- Ticket URL: <https://trac.macports.org/ticket/52414#comment:19> MacPorts <https://www.macports.org/> Ports system for the Mac operating system