Opened 5 years ago
Closed 5 years ago
#58761 closed defect (worksforme)
cmake 3.15.0: can't destroot on Lion
Reported by: | lemzwerg (Werner Lemberg) | Owned by: | michaelld (Michael Dickens) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | lion | Cc: | |
Port: | cmake |
Description
[macOS 10.7.5 11G63]
[Xcode 4.6.3 4H1503]
[cxx_stdlib libc++]
[macports-ports a26156007c466407413cffe2f619426e7147f59a]
[macports-base e09517b2ebf0ca18cd7b6e66ac3ffafba48296b3]
Upgrading cmake from 3.14.5 to 3.15.0 fails in the 'destroot' stage with quite a weird error:
dyld: Library not loaded: /usr/local/lib/libzstd.1.dylib Referenced from: /opt/local/lib/libarchive.13.dylib Reason: image not found
otool -L libarchive.13.dylib
only reports the standard MacPorts library dependencies from /opt/local/lib
– on my MacOS box, directory /usr/local/lib
doesn't exist at all...
Attachments (1)
Change History (7)
Changed 5 years ago by lemzwerg (Werner Lemberg)
Attachment: | main.log.xz added |
---|
comment:1 Changed 5 years ago by jmroot (Joshua Root)
Owner: | set to michaelld |
---|---|
Status: | new → assigned |
comment:2 Changed 5 years ago by mf2k (Frank Schima)
Keywords: | lion added; Lion removed |
---|
comment:3 Changed 5 years ago by kencu (Ken)
So on your system, that libarchive
would be one you built yourself. The only way it could have been linked against a zstd
in /usr/local/lib
is that you must have had zstd
installed from some other source (either installed from a package, or you installed it from source yourself, or homebrew installed it) to get it in /usr/local/lib
. Then you build MacPorts libarchive
and it found that zstd
to link against, and then you later on deleted it.
I have a stock 10.7.6 system, and all is well there:
$ otool -L /opt/local/lib/libarchive.13.dylib /opt/local/lib/libarchive.13.dylib: /opt/local/lib/libarchive.13.dylib (compatibility version 17.0.0, current version 17.3.0) /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.0.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.4.0) /opt/local/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.3.8) /opt/local/lib/liblz4.1.dylib (compatibility version 1.0.0, current version 1.8.3) /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.11) /opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.7.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
So -- I would just triple check that /usr/local
is totally empty. Then make sure you have zstd
installed port -v installed zstd
.
And then unistall and reinstall libarchive
to make it right:
sudo port -f uninstall libarchive sudo port -v install libarchive
and you should get a clean version.
comment:4 Changed 5 years ago by kencu (Ken)
If your libarchive
has identical linkages to the stock one I posted above, and yet MacPorts
base is somehow thinking it is linking against a non-existant zstd
in /usr/local/lib
, then that would be very strange indeed, and I would have no idea how base could think that.
comment:5 Changed 5 years ago by lemzwerg (Werner Lemberg)
/usr/local/lib
*is* empty, and otool
shows the same linkage as in comment #3. However, rebuilding libarchive
helped, and installation of cmake
then succeeded.
No idea what went wrong, but the issue is now solved. Thanks for the help, and please close this issue.
comment:6 Changed 5 years ago by michaelld (Michael Dickens)
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
log file of building cmake 3.15.0