I can share pretty much anything that could be helpful, all of these dylibs are in-house compiled versions of open source projects so I'm going to link to a XZ archive containing a few of those that are most often involved in the crashes (in this case openCASCADE, specifically libTKBO.7.dylib). There is no difference between the working and the crashing case as I do not modify the dylibs other than applying the copy, delete, replace workaround if needed. One thing that makes me believe it might even be some weird caching or APFS issue is the fact that, if I create a simple "Hello World" C program and link it against one of the dylibs it will normally run just fine except in the case where otool would also crash. If I get a crash from otool -L and try to run the binary linking to the affected dylib it will also crash pointing to a failure to verify the code signature of @rpath/NAME_OF_LIBRARY. https://www.icloud.com/iclouddrive/0m1cKLZsmmdbXfK7xg9VORzFA#openCASCADE_sample it's shared for meaton3 apple.com, libTKBO.7.dylib is one of the libs mostly causing the problem. A few more details to my working environment: MacBook Air M1, late 2020 macOS Big Sur 11.5.2 (issue also happened on 11.5.1) Xcode 12.5 all files are stored on an external USB 3 SSD formatted with APFS

That sounds very reasonable to me and I can follow your explanation as to why this would cause cache issues (the thread you linked to gives me "Error - Access Denied / content not found" though). In our setup here those libs are pulled from a repo once and pretty much never get touched again later though - other than being read by otool and friends / copied into a final .app bundle. Could there be any system process in the background causing this?

A small update - I created a disk image containing all of our dependency dylibs and verified they all could be read by otool -L before mounting the disk image read-only and using it as a source for headers and linking against the dylibs. Lo and behold about an hour later I get the same issue even though the image is mounted read-only so nothing should have changed in those libraries at all.

The dylibs always get quarantined on the first SVN checkout as the system deems them "downloaded from the internet" and since they all carry only an adhoc signature. However once removed neither they nor the disk image got the quarantine xattr again. I'm currently investigating another theory - it looks like someone messed up the check in and instead of a symlink "libTKBO.7.dylib" pointing to "libTKBO.7.5.0.dylib" we have copies so there's a "libTKBO.7.dylib" which is a copy of "libTKBO.7.5.0.dylib" carrying the same adhoc signature that was created on the original.

I also filed FB15474213 referencing all other Feedbacks here mentioned so far - fingers crossed. I'd love to ship this app but as is I just can't.