On 20 March 2017 at 09:50, Daniel P. Berrange <berra...@redhat.com> 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*!!!
http://stackoverflow.com/questions/11372872/what-the-role-of-libcglibc-in-our-linux-app
"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
<http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
