cpython linker

We are having the issue with our … cpython-39-darwin.so

I don’t see what the actual problem is here?

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

/usr/lib does not have those libraries. However on the machine it was created it works fine. But in another machine it crashes that we suspect it is due to those two libraries. As I do not understand where those two libraries are and how they get loaded.

／usr／lib does not have those libraries.

That’s expected. I explain why that’s the case in this post. And for more of the backstory, see An Apple Library Primer.

But in another machine it crashes that we suspect it is due to those two libraries.

That’s unlikely. Both of these libraries should be available in the dynamic linker shared cache.

As I do not understand where those two libraries are

libSystem.B.dylib is the runtime implementation of the System framework. This provides all the standard C library interfaces, all the system calls (like open), and a bunch more. It’s roughly equivalent to ‘libc’ on other platforms.

libc++.1.dylib is the C++ standard library. Apple uses the LLVM one. Other platforms after use the GNU one, libstdc++.

and how they get loaded.

The dynamic linker loads them from its shared cache. Try this:

1. In Xcode, create a new project from the macOS > Command Line Tool template, selecting C++ as the language.

2. Build and run it, just to make sure things work.

3. Dump the libraries it imports:

   % otool -L Test729401 
   Test729401:
       /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
   

4. Now run it again, setting DYLD_PRINT_SEARCHING. You’ll see this:

   % DYLD_PRINT_SEARCHING=1 ./Test729401
   dyld[4412]: find path "/usr/lib/libc++.1.dylib"
   dyld[4412]:   possible path(original path on disk): "/usr/lib/libc++.1.dylib"
   dyld[4412]:   possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libc++.1.dylib"
   dyld[4412]:   possible path(original path): "/usr/lib/libc++.1.dylib"
   dyld[4412]:   found: dylib-from-cache: (0x000A) "/usr/lib/libc++.1.dylib"
   dyld[4412]: find path "/usr/lib/libSystem.B.dylib"
   dyld[4412]:   possible path(original path on disk): "/usr/lib/libSystem.B.dylib"
   dyld[4412]:   possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib"
   dyld[4412]:   possible path(original path): "/usr/lib/libSystem.B.dylib"
   dyld[4412]:   found: dylib-from-cache: (0x00AB) "/usr/lib/libSystem.B.dylib"
   Hello, World!
   

   which shows how the dynamic linker was able to resolve those imports.

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

Hi

The issue is not this. We use cmake and I am making sure that it is using Apple's c++. But somehow it is picking up libstd++ which I assume it is coming from using gnu or something. Any idea ?

dyld[75191]: find path "/usr/lib/libstdc++.6.dylib" dyld[75191]: possible path(original path): "/usr/lib/libstdc++.6.dylib" dyld[75191]: not found: "/usr/lib/libstdc++.6.dylib"

Thank you

Any idea?

Not really. There’s a world of third-party stuff in here that I don’t maintain expertise in.

However, you should be able to track this down. Apple platforms implement a two-level namespace, so when a Mach-O image references a symbol it records both the name of the symbol and the library it came from. These references are set up by the static linker when it creates the Mach-O image from a set of Mach-O objects. Consider this:

% cat main.c 
#import <stdio.h>

int main(int argc, char ** argv) {
    printf("Hello Cruel World");
}
% clang -c main.c     
% clang -o main main.o
% nm -m main.o 
0000000000000000 (__TEXT,__text) external _main
                 (undefined) external _printf

So main.o has no idea where printf is supposed to come from. In contrast:

% nm -m main  
0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header
0000000100003f70 (__TEXT,__text) external _main
                 (undefined) external _printf (from libSystem)
% otool -L main  
main:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

The static linker knows that printf is in the System framework and so has recorded that fact in the Mach-O image.

Note The static linker automatically includes the System framework so you don’t need to supply that as an argument. There’s some way to disable this but the details have fallen out of my head right now.

So, you should be able to track this down by working backwards through your build products to find out which linker invocation is bringing in the non-standard (-: standard C++ library.

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