1

How does a function resolve in Linux at runtime? Is it purely based on the name and and some "symbol table" as I've imagined, or is it a hardcoded address of some sort? I read online that you have to recompile for Musl libc, and for glibc, yet shouldn't they have the same symbol exports? How do symbols work?

1 Answer 1

1

Since the program is loaded into memory before run time, functions map to certain memory addresses, relative to the base address. All calls to a function are compiled as the relevant memory address. The symbol table is often included in a binary, but to reverse address mappings to human-readable names for debugging purposes. Try nm -D /usr/lib/libc.so.6 on a typical Linux installation to see glibc's symbol table.

In terms of binary compatibility, glibc and Musl both implement shared standards, but there are a variety of idiosyncrasies that must be reflected in their own header files (hence why there isn't a univeral package of standard library headers in most Linux distros - they're bundled with each library instead).

From musl's FAQ:

Is musl compatible with glibc?

Yes and no. At both the source and binary level, musl aims for a degree of feature-compatibility, but not bug-compatibility, with glibc. When applications that work with glibc fail to compile against musl, the cause will usually be one of the following:

  • Assuming that including one header will cause symbols from another unrelated header to be exposed. This is an application bug, and fixing it is as simple as adding the missing #include directives.
  • Using implementation details from the glibc headers which were not meant to be exposed to applications. This is also an application bug, and it can usually be fixed by search-and-replace (e.g. replacing __pid_t with pid_t in the source).
  • Use of an interface that’s not implemented in musl. This can only be fixed by making the application’s use of the interface optional, or by extending musl to support the missing interface.

Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .