Bug 169414
| Summary: | Static glibc linkage sucks in the whole universe | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andy Ross <andy> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-28 07:08:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
That's the price to pay for a feature complete C library. Static linking has never been recommended and is certainly not very high among glibc goals. If you want small statically linked binaries and don't mind feature incomplete C library, there are alternatives created just for that purpose (dietlibc, uclibc, klibc, ...). What about the static binaries that Red Hat is shipping as part of its own product? Are those "not recommended"? Again, see bug 169412 ... |
This on my x86_64 box: $ echo 'int main(){return 0;}' > test.c $ gcc -static -o test test.c $ ls -l test -rwxrwxr-x 1 andy andy 559884 Sep 27 16:37 test Glibc's notion of the world includes half a megabyte of omnipresent static... stuff. See bug 169412 for a practical problem related to this. I tried stuff like linking against malloc() and printf() (perenial "big chunk of libc" entry points) and the size grew by only a few tens of kilobytes. Something is pulling in *far* more than it should. Static linking isn't often necessary or useful, but it should at least be possible without wasting 500k for every binary.