On 15 March 2017 at 17:22, Florian Weimer <fwei...@redhat.com> wrote:
> Please read again what I wrote. > > In a container (and multi-toolchain) world, static linking of glibc does > not add a significant support burden because we cannot use glibc as an > abstraction layer for the kernel, unlike what other operating systems do. > (This is independently of what is actually supported.) > Please try to have look first on "dnf list | grep -- - static" list maybe after this you will realise that current list of packages with static libraries is not enough to have such static linking dev environment because *in last years many packages already dropped building and packaging static libraries,* and no one been crying by this. For cases which will mainly require for some reasons static linking with libc.a probably it would be good consider switch to uClibc because in such cases size of the binaries probably is quite important. I have no idea from where it comes but glibc never was and never will be abstraction layer for the kernel on any existing operating systems because kernel provides abstraction layer on which sits (g)libc. I'm still greping across all packages repos but so far I found only two fedora packages which requires during build glibc-static. One is binutils and second one is golang. Both packages uses static linking in own test suits. To test binutils ld that it able to link elf binary or DSO using some test static libraries you don't need to link such test binary with libc.a. Will have shortly full assessment of what really is using in Fedora glibc-static. kloczek -- Tomasz Kłoczko | 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
