Bug 169414 - Static glibc linkage sucks in the whole universe
Summary: Static glibc linkage sucks in the whole universe
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-28 00:05 UTC by Andy Ross
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-09-28 07:08:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andy Ross 2005-09-28 00:05:16 UTC
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.

Comment 1 Jakub Jelinek 2005-09-28 07:08:27 UTC
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, ...).


Comment 2 Andy Ross 2005-09-28 14:03:40 UTC
What about the static binaries that Red Hat is shipping as part of its own
product?  Are those "not recommended"?  Again, see bug 169412 ...


Note You need to log in before you can comment on or make changes to this bug.