4

I have an application which is normally built and executed using GLIBC. One of my users is attempting to use it on a platform built with the MUSL C library (which claims to be GLIBC compatible).

When doing so they are getting an ldd symbol resolution failure for __strftime_l, which MUSL implements but doesn't actually export as an externally visible symbol.

Is there any way to stop the application build against GLIBC turning functions like strftime_l() into to the __ prefixed versions such as __strftime_l() in the run-time resolved symbol table?

solidpixel
  • 10,688
  • 1
  • 20
  • 33
  • 1
    Also, in my simple testing with G++ and GLIBC I can't reproduce this, so if anyone knows under what conditions the decision to use the `__` prefixed versions is taken, that would also be useful to know. – solidpixel Dec 23 '19 at 12:09
  • 1
    Neither the [`time.h` header for GLIBC](https://github.com/lattera/glibc/blob/master/time/time.h) nor [the MUSL `time.h`](https://github.com/rofl0r/musl/blob/master/include/time.h) are doing anything strange with `strftime()`, so I suspect your user's compilation environment. Try to get this user to give you the preprocessor output from `gcc -E ...` – Andrew Henle Dec 23 '19 at 18:03

1 Answers1

2

MUSL C library (which claims to be GLIBC compatible).

From musl FAQ:

Is musl compatible with glibc?
... At present, some glibc-linked shared libraries can be loaded with musl ...
all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2

If you want to support musl, build (and test) a separate version of your application against it. Both you and your users will be much happier with the end result.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362