Good morning Paolo, good morning all, How are you? I hope all is well with you. Please find below a quote from an Apple engineer from the article I recommended to you yesterday (https://developer.apple.com/forums/thread/655588):
> Given the above reality, the libraries in /usr/lib are no longer needed: > Developer tools should be looking at the stub libraries in the appropriate > SDK. > The runtime doesn’t use these libraries because they’ve been rolled into the > dynamic linker shared cache [4]. > And that’s why they were removed. > > This is fine if you’re using Xcode, or Apple’s command-line tools, because > they know how to look inside an SDK for headers and stub libraries. If you’re > using third-party tools then you need to consult the support resources for > those tools to find out how they’ve adjusted to this new reality. In your > case the critical point is the linker. If your third-party tools use the > Apple linker then you should just be able to point the tools at the > usr/include directory within the appropriate SDK. Our linker will > automatically use any stub libraries that it finds. According to this the physical libraries on your system (*.dylib) files became stub libraries (*.tbd). Apple-native tools, C and C++ compilers from Xcode Command Line Tools will know how to work with these stub libraries. Third-party tools (the GNU compilers) will need adapting to this new reality of the Apple-world and learn how to work with the stub libraries. Paolo, can you check with ‘tool -L <exe_file>’ and ‘dyld_info -dependents <exe_file>’ what are the dependencies of your executable? Here is another good article on Apple Developer Forums on libraries and linking: https://developer.apple.com/forums/thread/715385 > The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, > so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced > that dee-lid, but some folks say di-lid and others say dee-why-el-dee. > IMPORTANT Third-party executables must use the standard dynamic linker. Paolo, can you double check and make sure your compilation procedure uses Apple’s dynamic linker (/usr/lib/dyld)? All in all, as a rule of thumb, to obtain less problems during compilation and streamline general research and development work use native, vendor-provided toolchains. For example, on Apple try to use Apple toolchain, on Intel—Intel toolchain, on AMD—the AMD, on ARM—the ARM. This is also extremely important to achieve the highest possible performance on a given CPU. I cannot stress this enough, this seems to be a common problem in the research world (this is where my background lies too). Researchers naively use GNU and believe it will result in the best performance. No. Use vendor compilers and libraries to have the highest performance mathematical operations. For example, on Intel architectures, use Intel compilers, Intel OpenMPI library, Intel MPI library and Intel MKL. Returning to our topic, Apple notoriously does not support Fortran and has no native Fortran compiler. The route to using a __native__ Fortran compiler is closed to us. A possible solution may be to use ‘flang’, a Fortan compiler from an LLVM suite (https://flang.llvm.org/docs/). As I understand it, it is in active development, but may not yet be ready for a production use. Another option may be commercial Fortran compilers for Mac. For example, NAG’s Fortran compiler: https://nag.com/fortran-compiler/ Finally, we have our beloved GNU Fortran compiler. I don’t know, what is the status of the latest ‘gfortran’ to support Apple’s stub libraries. Maybe more experienced MacPorts users would complement my answer here? The fact that GNU toolchain needs to be compiled for your iMac with M3 is probably due to the absence of pre-compiled binaries of the ‘gcc14’ and ‘libgcc14’ ports for your platform (Sequoia) and architecture (Apple M3). My basic understanding of MacPorts is that, if your platform and architecture are well established, there will be a pre-compiled binary of the port that you can simply download and install. There will be to compilation from sources. On the other hand, if your platform + architecture are new, no pre-compiled binaries exist in the online repositories of MacPorts and these ports will be compiled from source. Experienced MacPorts users, please correct me, if I'm wrong. I hope all of this was helpful. Thank you all and have a wonderful day ahead! — Best wishes, Maxim Maxim Abalenkov \\ [email protected] +44 7 486 486 505 \\ www.maxim.abalenkov.uk > On 1 Oct 2024, at 10:26, Maxim Abalenkov <[email protected]> wrote: > > Hello Paolo, > > How are you? A quick search on the Internet results in the following links: > > https://stackoverflow.com/questions/74909796/missing-libsystem-b-dylib-file-on-macos > https://stackoverflow.com/questions/70549365/why-are-my-system-libraries-and-frameworks-not-visible-in-macos-monterey > https://developer.apple.com/forums/thread/655588 > > The article on the Apple Developer forum may be most helpful for you. Thank > you and have a great day ahead! > > — > Best wishes, > Maxim > > Maxim Abalenkov \\ [email protected] > +44 7 486 486 505 \\ www.maxim.abalenkov.uk > >> On 1 Oct 2024, at 10:16, P. Denti via macports-users >> <[email protected]> wrote: >> >> Failure starting with OS Sonoma, now with Sequoia. >> Processor is M3 on iMac. >> >> The following message in Sonoma: >> >> paolo in ~/Desktop/nisclue240 $ ./nisclue >> dyld[78445]: dyld cache '(null)' not loaded: syscall to map cache into >> shared region failed >> dyld[78445]: Library not loaded: /usr/lib/libSystem.B.dylib >> Referenced from: <A5EF4235-E54A-3375-A9DC-4278E534593E> >> /Users/paolo/Desktop/nisclue240/nisclue >> Reason: tried: 'usr/lib/libSystem.B.dylib' (no such file), >> '/System/Volumes/Preboot/Cryptexes/O/uS/usr/lib/libSystem.B.dylib' (no such >> file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache) >> Abort trap: 6 >> >> Analogous response in Sequoia. >> >> Additional information: >> The same job runs until completion on a previous iMac with processor i7 >> with OS Monterey. >> >> nisclue from nisclue.f is the only job in a dozen of similar jobs that >> refuses to work; >> a common feature of these jobs is dealing with large matrices. >> >> If this information is insufficient, and sources and data involved are >> required, I will post. >
