Opened 10 years ago
Closed 10 years ago
#44065 closed defect (fixed)
libarchive opportunistically links with libnettle
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | tobypeterson |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.99 |
Keywords: | Cc: | cooljeanius (Eric Gallager) | |
Port: | libarchive |
Description
libarchive opportunistically links with libnettle:
$ port installed libarchive The following ports are currently installed: libarchive @3.1.2_0+universal (active) $ port deps libarchive Full Name: libarchive @3.1.2_0+universal Library Dependencies: bzip2, zlib, openssl, libxml2, xz, lzo2 $ otool -L /opt/local/lib/libarchive.dylib /opt/local/lib/libarchive.dylib: /opt/local/lib/libarchive.13.dylib (compatibility version 15.0.0, current version 15.2.0) /opt/local/lib/libnettle.4.dylib (compatibility version 4.0.0, current version 4.5.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 6.0.0, current version 6.5.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/libxml2.2.dylib (compatibility version 12.0.0, current version 12.1.0) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
libarchive should either declare a dependency on nettle, or should not use nettle.
Change History (3)
comment:1 Changed 10 years ago by cooljeanius (Eric Gallager)
comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
r133708 (maintainer timeout)
Note: See
TracTickets for help on using
tickets.
Or have a variant for it.
Edit: the libiconv linkage shown there is not listed as a dependency, either. So much stuff already depends on libiconv, though, that in that case, I would just go and add the dependency instead of thinking about a variant for it.
(btw checking both of the linkages with
nm
confirms that symbols from the libraries are actually used in both cases)