On 20 March 2017 at 09:50, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
> I've already described this multiple times trying to use different
> descriptions/analogies about well known *glibc NSS ABI issue*.
> You cannot fix this issue in *any libc implementation which is using NSS*.
Apps don't need to make use of the affected APIs in glibc and even if they
do the problem is not a show stopper as long as you keep the app build in
sync. So while this is a potential problem, it is not a blocking problem
that justifies throwing the baby out with the bath water.
People are linking static binaries to not be forced to recompile and/or relink such binaries.
In other words what you wrote is in contradiction with typical case when static binaries are used.
Try to write simple "hello_nss" program communicating over network establishing connectivity using host name.
Such program will be using network NSS map to resolve host name to IP over "hosts" NSS map.
When you will have static binary try to execute "strace -e trace=file ./hello_nss" and you will see loading by such program libnss_dns.so and libnss_files.so DSOs.
Such risk from NSS area is probably biggest in context of some random Linux users trying to build and use 100% statically linked binaries.
Typical upgrade scenario with NSS issue which may hit hardly distribution however is with other NSS maps.
In such upgrade scenario some programs are changing user and group during upgrade on just written to the fs tree new files.
Such program will be using "passwd" and "group" NSS maps to resolve user names and groups to UIDs and GIDs.
> Other reasons are like constant changes in kernel<>userspace changes on all
> unices are part of the problem as well.
Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.
Really? Hmm .. [censored =8-O] so it must be something really, really new .. !!!
(OKi .. quick unpack glibc source code and .. )
[tkloczko@domek glibc-2.25-80-ga10e9c4]$ ./configure --help `configure' configures GNU C Library (see version.h) to adapt to many kinds of systems.
[..]
--enable-kernel=VERSION compile for compatibility with kernel not older than
VERSION
So please explain why in glibc autoconf still is such option? Can you do this?
Maybe someone forgot to remove this option???
Just do what I did unpacking glibc source code and try to read glibc ChangeLog* files looking for entries documenting some adjustments between kernel API and glibc. This area is on constant move like lava.
~99.99% of the even highly skilled and experienced programmers may have impression that everything here is still and static.
Yes, it is only .. impression!!! Thanks to LIBC all those changes are not (usually) visible.
This is one of the fundamental purposes of every Unix libc!!!
"You cannot directly make system calls in the same way that you call normal functions because calls to the kernel aren't normal function calls, so they can't be resolved by the linker. Instead, architecture-specific assembly language thunks are used to call into the kernel - you can of course write these directly in your own program too, but you don't need to because libc provides them for you."
And one more time ..
Did you had a look on Documentation/ABI content in kernel source tree?
Did you read with understanding paragraph from Documentation/ABI/README which I've quoted in this thread?
Please don't get me wrong. I'm not trying to attack you personally even if it may look that I'm doing exactly this.
This discussion is on pure technical/engineering background.
I'm a bit frustrated or anger that I'm not able to express such subject enough clearly ..
(I'm not native English speaker and if we will be talking using Polish it would be way easier to me :) )
So .. Daniel you are working in RedHat. So .. in RedHat probably still is working Ulrich Drepper who is glibc maintainer.
Offer him free lunch to have opportunity to talk with him face about this subject (you can send me the bill after all :) ).
You can do this because if not every day probably time to time you can have him on "normal beret throwing distance".
(I'm in UK so I would be forced to use ballistic beret).
Please don't try to convince me. Rally forget about me. I'm probably one of the smallest beatles here.
Just please sit down with him and try to convince him that there is no at all risk here.
kloczek
--
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
