My libSystem.B.dylib is missing from my mac

When I try to run a simple executable from Cmake, I get this error.

dyld[5005]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed
dyld[5005]: Library not loaded: /usr/lib/libSystem.B.dylib
  Referenced from: <7EB1C677-BB05-338C-8B29-CC2803CB8C21> /Users/pop/Desktop/Lang
  Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache), '/usr/local/lib/libSystem.B.dylib' (no such file)

I have tried looking for my file

sudo find / -name libSystem.B.dylib

but not luck. I am using an M1 chip and Ventura 13.1. Please ask for more details if you need them, as I really have no idea what to do about my problem.

The dynamic libraries are not linked to the previously expected locations. Try first this export DYLD_LIBRARY_PATH=$LD_LIBRARY_PATH and than repeat your cmake

I have tried looking for my file

sudo find &#x2F; -name libSystem.B.dylib

but not luck.

That’s expected, because, on modern systems, this dynamic library has been rolled into the dynamic linker shared cache. See this post for the specifics and An Apple Library Primer for more context.

The dynamic linker is supposed to find this library in its shared cache. Consider this:

% cat hello.c                   
#include &lt;stdio.h>

int main(int argc, char **argv) {
    printf("Hello Cruel World!\n");
}
% clang hello.c                 
% .&#x2F;a.out 
Hello Cruel World!
% DYLD_PRINT_SEARCHING=1 .&#x2F;a.out
dyld[64879]: find path "&#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib"
dyld[64879]:   possible path(original path on disk): "&#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib"
dyld[64879]:   possible path(cryptex prefix): "&#x2F;System&#x2F;Volumes&#x2F;Preboot&#x2F;Cryptexes&#x2F;OS&#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib"
dyld[64879]:   possible path(original path): "&#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib"
dyld[64879]:   found: dylib-from-cache: (0x00AB) "&#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib"
Hello Cruel World!

When you set DYLD_PRINT_SEARCHING the dynamic linker logs information about where it searched for libraries, and you can see that it found libSystem.B.dylib in its shared cache.

So, the question here is why that’s not happening for your program? The syscall to map cache into shared region failed message is obviously part of the problem. Some spelunking on the ’net pointed me back to DevForums, and specifically this thread. And if I add a huge static array to my test project:

% cat hello.c 
#include &lt;stdio.h>

char map[0x7fffffff];

int main(int argc, char **argv) {
    printf("Hello Cruel World!\n");
}

I’m able to reproduce the problem:

% clang hello.c
% .&#x2F;a.out      
dyld[33592]: dyld cache &#039;(null)&#039; not loaded: syscall to map cache into shared region failed
dyld[33592]: Library not loaded: &#x2F;usr&#x2F;lib&#x2F;libSystem.B.dylib
…
zsh: abort      .&#x2F;a.out

Does your program use huge static arrays? If you run size against it, what do you see?

% size a.out 
__TEXT  __DATA      …
16384   2147483648  …

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm not the OP, but I do have this problem and I do have huge static arrays:

__TEXT	__DATA	__OBJC	others	dec	hex
868352	2761801728	0	4295016448	7057686528	1a4abc000

My gfortran setup produces working code for examples without such large static arrays. Any advice appreciated.

In a C-based language arrays and pointers are (more or less :-) the same thing, so you can fix a problems like this by allocating your array using malloc. I’m not sure how practical that is in your setup.

The other common workaround is to move stuff out of your main executable and into a shared library. Again, I’m not sure how practical this is for you.

Honestly, I think your best option here is to raise this issue with your tools vendor. You can’t be the first of their customers to hit this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

cheesedanishboy.

I am having the same or similar issue. I am not an expert whatsoever so I will be as descriptive as possible. I got a new mac M2 and I installed XCODDE, XCODE command tools, and installed gfortran using homebrew. I compailed my code and I ran it and I got the following

dyld[3244]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed dyld[3244]: Library not loaded: /usr/lib/libSystem.B.dylib Referenced from: <DD0D5B50-62AD-3AB4-942A-1AA665A235F4> /Users/gamalakabani/Applications/TALYS_CODE/talys/bin/talys Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache), '/usr/local/lib/libSystem.B.dylib' (no such file) ./verify: line 12: 3244 Abort trap: 6 $talys < talys.inp > talys.out

I have been looking for the location of libSystem.B.dylib and learned that the new macs are "different." I reinstalled XCODE, command tools, gfortran, etc. to no avail.

I just want to fix this issue using laymans terms.

Any help will be appreciated.

Thanks

I just want to fix this issue using laymans terms.

Your third-party tooling is generating a huge static data structure, something that’s not compatible with the Apple silicon runtime model [1]. You have three choices:

  • You can change your code to not use a huge static data structure. In a C-based language you’d do that by allocating the data structure with malloc. I can’t help you on the Fortran side of things.

  • You can move that data structure into a dynamically linked library. Again, I know how to do that with Apple tools but I can’t help you with third-party tools.

  • You can raise this issue with your tool’s vendor via their support channel.

Honestly, I recommend the latter. As I said above, you can’t be the first of their customers to hit this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I’m not assigning blame here, just describing a reality that’s existed since Apple silicon was first released.

Thanks eskimo for your reply. It is the first clear answer I found after struggling against this problem since I got my new macbook M2 a few weeks ago. But your "recommended" advise "You can raise this issue with your tool’s vendor via their support channel" is not relevant at all. All the mac users are not using tools having a "vendor"! Mac computers are extensively used in the academic research, where people develop their own codes in various domains, and do not use any commercial codes with "vendors". That is my case. Changing the way memory is allocated in my codes will be a huge piece of work. I don't really understand what changed concerning the memory management on M procs and why it has been done but it is really a bad news. I had hopped that some compiler options or system configuration could fix the problem but your post is quite clear about that.

Mac computers are extensively used in the academic research, where people develop their own codes in various domains, and do not use any commercial codes with "vendors".

Understood. I’m using “vendor” in an abstract sense. I have another favourite phrase that I use that might be more to your liking, namely “escalate this via the support channel for your tools”. So:

  • If these are commercial tools, you should follow the escalation path defined by the vendor.

  • Most non-commercial tools also have an escalation path, usually in the form of an issue tracker, a support mailing list, a discussion board, or whatever.

  • And if neither of the above apply, you are the tools vendor (-:

I’m happy to help tool authors improve their compatibility with Apple platforms because that represents a significant ‘force multiplier’: I help one person and many others benefit.

I can do that here or, even better, in the context of a DTS tech support incident (TSI). If you have a TSI to spare, it’s fine for you to open a TSI and then invite someone from the tool project to participate.

However, that discussion requires engagement from someone who knows the tool’s internals. If you’re using a tool created by someone else, you need to either get a commitment from them to engage in that discussion or, if it’s open source, learn enough about how it works so that you can perform that role.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Well, I have written the simplest program to describe the problem: 7 lines of fortran!

      parameter (n=267500000)
      real*8 x(n)
c      common /bid/ x
c
      do i=1,n
        x(i)=i
      enddo
      print*,x(n)
      end

n=267500000 is the limit I found by trial an error. It is 1.993 GB. This program works, while it fails with n=267600000 (1.9938 GB)

dyld[41138]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed dyld[41138]: Library not loaded: /usr/lib/libSystem.B.dylib Referenced from: <2B29D6C7-6D46-3945-9ABD-055CC298981B> /Users/jouve/Test_mem/testmem Reason: tried: '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache), '/usr/local/lib/libSystem.B.dylib' (no such file)

Putting the big array in a common zone (which is commented here) is a classical way to avoid the limits on stack size, but does not change anything here.

The line "print" is only there to avoid smart compilers to "optimize" the whole program and reduce it to nothing if they find out that this piece of code does nothing at all :)

Of course it works on old Mac-intels and linux computers with any value of "n".

This is a real problem for scientists using legacy codes. It's also very confusing because the error only appears if large enough arrays are declared.

My numbers don't quite align with the above, but is shows the issue. Here's what I get, runinng first with the big array and then the small one:

fuka:~ 11:44> gfortran test.f90 fuka:~ 11:44> a.out dyld[22801]: dyld cache '/System/Library/dyld/dyld_shared_cache_arm64e' not loaded: syscall to map cache into shared region failed dyld[22801]: Library not loaded: '/usr/lib/libSystem.B.dylib' Referenced from: '/Users/stefan/a.out' Reason: tried: '/System/Library/Frameworks/JavaVM.framework/Libraries/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file), '/usr/local/lib/libSystem.B.dylib' (no such file) Abort fuka:~ 11:44> size a.out __TEXT __DATA __OBJC others dec hex 16384 2140012544 0 4295000064 6435028992 17f8ec000 fuka:~ 11:44> gfortran test.f90 fuka:~ 11:45> a.out 26750000.000000000
fuka:~ 11:45> size a.out __TEXT __DATA __OBJC others dec hex 16384 214007808 0 4295000064 4509024256 10cc24000

I can change the array sizes but I don't know if it will be useful. So in some respects I'm the vendor. I could file a TSI, but I'm not sure I fully understand it. As far as I'm concerned, the example above says it all.

I can confirm that I am seeing this with a gfortran-compiled code which uses a 6GB static area, run on an M1 with a recent macOS (Darwin Kernel 23.2.0 as I can see in the terminal - it's a remote login, I have no idea how to convert it into the usual Apple OS names/version). Lowering it to 1GB fixes the issue, although that's of course not a real fix. It seems that the only way out is to use dynamic memory allocation instead, which is, in case of Fortran 77, MALLOC, and ALLOCATE for later Fortran dialects.

The error message is very confusing, of course, this is rather weird that a large static area breaks linking.

My libSystem.B.dylib is missing from my mac
 
 
Q