Re: Bug#757941: static linking: alternatives for glibc?

[Michael Tokarev <mjt@tls.msk.ru>]

07.10.2014 08:34, Steve Langasek wrote:
[]
>>> Was the removal of gethostby* APIs from the static glibc intentional?
> 
>> Yes.  It's the nsswitch problem.  The behavior of those APIs is controlled
>> by the nsswitch mechanism (specifically the hosts configuration), which is
>> inherently dynamic and doesn't support static linking.
> 
> It nevertheless is expected to work when the corresponding NSS modules are
> present.  It's not truly static, but the dynamic loading from static libc is
> supported.

When a statically linked app calls getaddrinfo() (it is getnameinfo not
gethostbyname), the call immediately returns "host not found, try again",
without any attempt to load anything or look for other files.

This is with jessie glibc.  With wheezy's glibc it worked when the right
nss modules are presnt (iirc anyway -- I know it worked, I didn't check
_how_ it worked).

> So bug #757941 should be reassigned to glibc, instead of claiming that this
> is somehow expected glibc behavior.
> 
>>> Perhaps glibc upstream would be willing to restore them?
> 
>> It would be nice, but I doubt you'll make much progress.  Lots of people
>> have complained about this over the years.
> 
> At issue here is a glibc regression, not the standard complaints about
> static glibc being not truly static.

Regression or not, but there are several other problems here.

First of all, glibc wasn't really intended to be used for static linking --
apps becomes huge in size and if it still tries to load nss modules or
other things, it means static isn't really static, it wont work that well
if your system is damaged (rescue purposes of busybox-static).

Other libcs exists which are intended to be used statically from the
ground up (uclibc, dietlibc, musl) and which works well in this context
and provides more than enough to be really useful and small.  That's
exactly why I used the subject I used: because I want to find a good
alternative to glibc, alternative which is intended for such use case.

Thanks,

/mjt