On 14 March 2017 at 20:15, Richard W.M. Jones <rjo...@redhat.com> wrote:
> These are very useful for building embedded systems, initramfses, > static linked binaries of large proprietary programs, and any case > where you don't want to depend on the system libraries. > There are still none of the real embedded systems distributions which are using statically linked binaries lined with glibc libraries. Fedora is not for embedded systems and using it on even small systems lie tv box (with +.5GB RAM) binaries with statically linked glibc will be waste of memory as already some other running processes will be using shared glibc libraries. In such use cases it will be better to link such binaries against uClibc or link some custom binary in busybox tree (both are part of the Fedora). Those packages does not provides shared libc ABI .. only static libc.a Glibc libc code as general libs simple is so bloated that using it on embedded systems as regular libc is pointless (and still is very hard even with constantly growing system memory of such systems). This is why projects like OpenWRT/Lede and other are not using glibc. Reality is that glibc provides some functions which are really hard to find even single binary which are using them. You can easily chop probably half of the glibc libc binary and 99.99% of whole Fedora distribution binaries will be working. Good that each library is not loaded as whole object into memory (paging) and only by this it does not hurts to much (hever whole library public symbols jump table must be fully initialized and loaded into memory so it is some noticeable cost of it ..). 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
