public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Chris Trawick" <hazard@lords.com>
To: <gcc-help@gcc.gnu.org>
Subject: gcc/binutils/glibc/linux static behavior (was RE: gcc -static pulls in entire libs)
Date: Fri, 18 Jan 2002 06:48:00 -0000	[thread overview]
Message-ID: <03b801c1a02f$36e44080$0401a8c0@nielsenmedia.com> (raw)
In-Reply-To: <01D4D419B1A4D111A30400805FE65B13070E4C78@nmrusdunsx1.nielsenmedia.com>

Any knowledgable ppl around today to answer these questions?

(sorry for the double post if this shows up twice, sent the original through
my work account last night and i'm not sure if it got through)

chris

----- Original Message -----
From: "Trawick, James" <James_Trawick@tvratings.com>
To: <gcc-help@gcc.gnu.org>
Sent: Thursday, January 17, 2002 9:09 PM
Subject: RE: gcc -static pulls in entire libs


> (sorry Serban, just filling the question out a little...  it is a curious
> phenominon)
>
> Consider the following C source:
>
> /* begin test.c */
>
> #ifdef DO_SIN
> #include <math.h>
> #endif
>
> #ifdef DO_PRINTF
> #include <stdio.h>
> #endif
>
> int main(){
>
> #ifdef DO_SIN
> sin(0);
> #endif
>
> #ifdef DO_PRINTF
> printf("baz!\n");
> #endif
>
> }
>
> /* end test.c */
>
> compiled several different ways:
>
> for d1 in "" -DDO_PRINTF
> do
> for lm in "" -lm
> do
> for d2 in "" -DDO_SIN
> do
> for static in "" -static
> do
> gcc -Os $d1 $d2 test.c -o testproc$static$lm$d1$d2 $lm $static
> done
> done
> done
> done
>
> (ignoring the errors when libm isn't linked in of course) We get the
> following executables:
>
> -rwxr-xr-x    1 root     root        13629 Jan 18 09:56 testproc*
> -rwxr-xr-x    1 root     root        13739 Jan 18 09:56
testproc-DDO_PRINTF*
> -rwxr-xr-x    1 root     root        13637 Jan 18 09:56 testproc-lm*
> -rwxr-xr-x    1 root     root        13763 Jan 18 09:56
> testproc-lm-DDO_PRINTF*
> -rwxr-xr-x    1 root     root        13878 Jan 18 09:56
> testproc-lm-DDO_PRINTF-DDO_SIN*
> -rwxr-xr-x    1 root     root        13768 Jan 18 09:56
testproc-lm-DDO_SIN*
> -rwxr-xr-x    1 root     root      1712216 Jan 18 09:56 testproc-static*
> -rwxr-xr-x    1 root     root      1713259 Jan 18 09:56
> testproc-static-DDO_PRINTF*
> -rwxr-xr-x    1 root     root      1712216 Jan 18 09:56
testproc-static-lm*
> -rwxr-xr-x    1 root     root      1713259 Jan 18 09:56
> testproc-static-lm-DDO_PRINTF*
> -rwxr-xr-x    1 root     root      1713413 Jan 18 09:56
> testproc-static-lm-DDO_PRINTF-DDO_SIN*
> -rwxr-xr-x    1 root     root      1712402 Jan 18 09:56
> testproc-static-lm-DDO_SIN*
>
> When linked statically, it appears that there's no difference in sizes
> whether one links in libm or not, nor when you're doing nothing at all (as
> in testproc-static).  I think the linker is doing good as far as not
linking
> unneeded symbols goes, but there appears to be some sort of process
> initialization that requires a whole bunch of other stuff.
>
> I don't know if this is a question for gcc, binutils, glibc, or linux
> itself, but what exactly is happening behind the scenes?  What's being
> initialized?  Is there a way to reduce or eliminate the amount of
resulting
> static code?  Is that a good idea?
>
> chris
>
> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]On
> Behalf Of Serban Simu
> Sent: Thursday, January 17, 2002 3:13 PM
> To: gcc-help@gcc.gnu.org
> Subject: gcc -static pulls in entire libs
>
>
> Hi,
>
> I found that "gcc -static" creates oversized binaries, possibly pulling in
> entire libraries rather than the necessary sections.
>
> I have the object file s.o, which uses libmath. I link it as follows, to
> produce the binaries s1, s2 and s3:
>
>     $ gcc -o s1 s.o /usr/lib/libm.a
>     $ gcc -o s2 -static s.o /usr/lib/libm.a
>     $ gcc -o s3 -static s.o -lm
>     $ ls -l s1 s2 s3
>     -rwxr-xr-x    1 serban   serban       5920 Jan 17 03:23 s1
>     -rwxr-xr-x    1 serban   serban     443521 Jan 17 03:23 s2
>     -rwxr-xr-x    1 serban   serban     443521 Jan 17 03:23 s3
>
> I'm using gcc version 2.95.4 20010703 (Debian prerelease)
>
> This behavior seems incorrect. Moreover, in case the system provides both
.a
> and .so versions of the libraries, there is no workaround for using
the -lm
> syntax. Without -static gcc will build the dynamically linked binary, and
> with -static it builds an oversized binary. "strip" only reduces its size
a
> little bit:
>
>     $ strip s2
>     $ ls -l s2
>     -rwxr-xr-x    1 serban   serban     397536 Jan 17 03:48 s2
>
> Is there a way to use the -lm syntax, with the -static option, but create
> the small binary? Are there any other options that will help not pull in
the
> entire lib?
>
> I would appreciate any info to help me understand this. Thank you!
>
> Serban Simu
> Software Eng., Digital Fountain

      reply	other threads:[~2002-01-18 14:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-17 18:10 gcc -static pulls in entire libs Trawick, James
2002-01-18  6:48 ` Chris Trawick [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='03b801c1a02f$36e44080$0401a8c0@nielsenmedia.com' \
    --to=hazard@lords.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).