On Mon, Mar 20, 2017 at 01:16:56PM +0000, Tomasz Kłoczko wrote: > 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.
I never said anything about either needing to upgrade or needing to resolve hostnames / user names / group names. I use Fedora to build statically linked binaries for certain embedded devices I build and they have no network connectivity, nor need to have user/group lookups. Nor do they receive yum updates. When I update the software, I simply build it again on latest Fedora packages. So the problem you describe are a non-issue in my usage of static libraries. > > 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? Some system calls are found to be broken by design & not extensible. In those cases Linux may introduces new syscalls with improved design to replace them. The old syscalls still exist in Linux. GLibc could try the new syscall, and fallback to the old syscall if missing. The configure arg is just a way to drop the fallback code if the platform doesn't need to care about running with old kernels. Linux hasn't broken ABI compatibility here - on the contrary it has intentionally maintained ABI compatibility by introducing a new syscall in parallel with the existing syscall, instead of simply changing the original syscall. > So .. Daniel you are working in RedHat. So .. in RedHat probably still is > working *Ulrich Drepper* who is glibc maintainer. Ulrich hasn't worked for Red Hat for many many many years. > 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. I'm not saying there is no risk. No one has ever suggested it works perfectly in all scenarios. I'm simply saying that there *are* valid usage scenarios where it works just fine and thus deleting this support from Fedora is wrong. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
