[MacPorts] #52414: libarchive port fails problem with -pthread argument to clang

MacPorts noreply at macports.org
Sun Oct 2 16:33:44 CEST 2016


#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



More information about the macports-tickets mailing list