On 10/28/2012 09:49 PM, Florian Weimer wrote:
* John Spencer:I don't think musl supports NSS, so your application will not play well with LDAP, mDNS etc.as long as the application that wants to be linked statically depends on these features (very unlikely) this doesn't matter a bit.This isn't something the application can control. With NSS, getaddrinfo can get data from mDNS, and getpwnam can get user information from LDAP, as configured by the system administrator. Both scenarios are actually quite common. If your application links against a different libc, it will not support NSS, and it will not have the behavior expected by users.
if you rely on non-standard behaviour, it's not the fault of someone providing proprietary statically linked applications. in that case you better get something in source form that you can compile against your non-standard libc.
and generally behave different than the rest of the system.*if* glibc follows the POSIX/C specs, they will behave identically.The specification doesn't cover how getpwnam etc. get their data. Different libcs have different behavior there.
indeed, that's "implementation defined behaviour".
You can link libc dynamically and the rest statically.this sounds like A Bad Idea. if you dynamically link one component, you can as well just dynamically link everything, because you'll lose the advantages of static linking.The libc ABI is extremely stable, much more so than other libraries.
i'd say it is extremely fragile because the ugly headers of glibc will pull in a lot of hideous internal __prefixed functions. also there's the split in multiple separated libraries like libc, libm, libpthread, libdl. if you depend for example on dlopen, and glibc decides to move it from -ldl into -lc, you lost.
in any case, there are linux systems based on non-glibc, and your binary will never work on them.
