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)

main.log.xz (24.3 KB) - added by lemzwerg (Werner Lemberg) 5 years ago.
log file of building cmake 3.15.0

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by lemzwerg (Werner Lemberg)

Attachment: main.log.xz added

log file of building cmake 3.15.0

comment:1 Changed 5 years ago by jmroot (Joshua Root)

Owner: set to michaelld
Status: newassigned

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: assignedclosed
Note: See TracTickets for help on using tickets.