Oddities with gcc/g++ linkage

Oddities with gcc/g++ linkage

[Alex Buell]

Hi guys,

I was messing with generating object files and linking them in separate
phases.

The code I was using is:
  
  #include <stdio.h>

  int main() {
      printf( "bool = %u\nshort = %u\nint = %u\nlong = %u\n",
              sizeof(bool), sizeof(short), sizeof(int), sizeof(long));
      return 0;
      }

First test:
	g++ sizeof.c -o sizeof
	strip sizeof

On my machine that gives a binary executable size of 44k!

Second test:
	g++ -c sizeof.c
	gcc sizeof.o -o sizeof -lc
	strip sizeof

On my machine this gives me a binary executable size of 3k!!

Third test:
	g++ -c sizeof.c
	g++ sizeof.o -o sizeof -lc
	strip sizeof

This gives me a larger executable size of 44k!

All three executables works fine. 

Can anyone explain such variances in binary size?

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.122 #43 Sat Sep 19 10:54:36 EDT 1998 One AMD 486 DX/4 processor, 49.77 total bogomips, 32M RAM

Re: Oddities with gcc/g++ linkage

[H.J. Lu]

> 
> Hi guys,
> 
> I was messing with generating object files and linking them in separate
> phases.
> 
> The code I was using is:
>   
>   #include <stdio.h>
> 
>   int main() {
>       printf( "bool = %u\nshort = %u\nint = %u\nlong = %u\n",
>               sizeof(bool), sizeof(short), sizeof(int), sizeof(long));
>       return 0;
>       }
> 
> First test:
> 	g++ sizeof.c -o sizeof
> 	strip sizeof
> 
> On my machine that gives a binary executable size of 44k!
> 
> Second test:
> 	g++ -c sizeof.c
> 	gcc sizeof.o -o sizeof -lc
> 	strip sizeof
> 
> On my machine this gives me a binary executable size of 3k!!
> 
> Third test:
> 	g++ -c sizeof.c
> 	g++ sizeof.o -o sizeof -lc
> 	strip sizeof
> 
> This gives me a larger executable size of 44k!
> 
> All three executables works fine. 
> 
> Can anyone explain such variances in binary size?
> 

I have no problems on Linux. Make sure you configued egcs with
--enable-shared.

-- 
H.J. Lu (hjl@gnu.org)

Re: Oddities with gcc/g++ linkage

[Alex Buell]

On Sun, 20 Sep 1998, H.J. Lu wrote:

> I have no problems on Linux. Make sure you configued egcs with
> --enable-shared.

Of course they are using shared libraries.

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.122 #43 Sat Sep 19 10:54:36 EDT 1998 One AMD 486 DX/4 processor, 49.77 total bogomips, 32M RAM

Re: Oddities with gcc/g++ linkage

[Martin von Loewis]

[g++]
> On my machine that gives a binary executable size of 44k!
[gcc]
> On my machine this gives me a binary executable size of 3k!!
[...]
> Can anyone explain such variances in binary size?

I get the same results, probably because I'm using the same
configuration (i386-pc-linux-gnu). To investigate, I run

g++ -o a a.cc -v --save-temps

This tells me that input, preprocessor output, assembler code, and
object file are about the same size in both cases. So it must be the
linking. Therefore, I run

g++ -o a a.cc -Wl,--verbose 

(assuming a GNU linker). The difference becomes quite clear, now:
libstdc++ is linked as well. ld takes the objects

stdstrbufs.o streambuf.o filebuf.o stdstreams.o

from this library, and needs some more libgcc objects in turn.

I'm not entirely sure *why* this is happening. I believe it is a libio
feature, where libio comes from libstdc++ in this case, instead of
libc. Adding -lc doesn't help, because libstdc++ is searched first.

Regards,
Martin

Re: Oddities with gcc/g++ linkage

[Alex Buell]

On Sun, 20 Sep 1998, Martin von Loewis wrote:

> I'm not entirely sure *why* this is happening. I believe it is a libio
> feature, where libio comes from libstdc++ in this case, instead of
> libc. Adding -lc doesn't help, because libstdc++ is searched first.

Rebuilding egcs-1.1b with --enable-shared should fix this, so I'm told.
I'm currently rebuilding egcs right now.

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.122 #43 Sat Sep 19 10:54:36 EDT 1998 One AMD 486 DX/4 processor, 49.77 total bogomips, 32M RAM

Re: Oddities with gcc/g++ linkage

[Alex Buell]

On Sun, 20 Sep 1998, Alex Buell wrote:

> On Sun, 20 Sep 1998, Martin von Loewis wrote:
> 
> > I'm not entirely sure *why* this is happening. I believe it is a libio
> > feature, where libio comes from libstdc++ in this case, instead of
> > libc. Adding -lc doesn't help, because libstdc++ is searched first.
> 
> Rebuilding egcs-1.1b with --enable-shared should fix this, so I'm told.
> I'm currently rebuilding egcs right now.

As a follow-up, yes giving the --enable-shared parameters fixes the
problem. Martin, I suggest you recompile egcs-1.1b with --enabled-shared
and see if that cures your problem. 

Binary executables are a lot smaller now. Great. :o)

Cheers,
Alex
--
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today!
 > ^ <  Peace, Love, Unity and Respect to all.

http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!

Linux tahallah 2.1.122 #43 Sat Sep 19 10:54:36 EDT 1998 One AMD 486 DX/4 processor, 49.77 total bogomips, 32M RAM

Re: Oddities with gcc/g++ linkage

[Martin von Loewis]

> As a follow-up, yes giving the --enable-shared parameters fixes the
> problem. Martin, I suggest you recompile egcs-1.1b with --enabled-shared
> and see if that cures your problem. 

I guess it would, but this is not my point (this wasn't even my
problem :-)

IMHO, it would be better if the relevant libio parts came from libc
instead of libstdc++, even when linking libstdc++ statically. But
then, I can't provide a fix, so we have to live with the work-around.

Thanks,
Martin

Re: Oddities with gcc/g++ linkage

[Alex Buell]

On Mon, 21 Sep 1998, Martin von Loewis wrote:

> I guess it would, but this is not my point (this wasn't even my
> problem :-)

I must have misread it. ;)
 
> IMHO, it would be better if the relevant libio parts came from libc
> instead of libstdc++, even when linking libstdc++ statically. But
> then, I can't provide a fix, so we have to live with the work-around.

It doesn't really matter anyway. Stripping and -O2 usually sorts things
out.

Cheers,
Alex.

---
 /\_/\  Legalise cannabis now! 
( o.o ) Grow some cannabis today! 
 > ^ <  Peace, Love, Unity and Respect to all.

Check out http://www.tahallah.demon.co.uk
NEWFLASH: Reece K. Selim (Freedows) is the Shithead of the Year. Congratulations! 
Linux lo-pc3035a 2.1.122 #25 Thu Sep 17 11:06:39 EDT 1998 i586 unknown

Re: Oddities with gcc/g++ linkage

[H.J. Lu]

> 
> > As a follow-up, yes giving the --enable-shared parameters fixes the
> > problem. Martin, I suggest you recompile egcs-1.1b with --enabled-shared
> > and see if that cures your problem. 
> 
> I guess it would, but this is not my point (this wasn't even my
> problem :-)
> 
> IMHO, it would be better if the relevant libio parts came from libc
> instead of libstdc++, even when linking libstdc++ statically. But
> then, I can't provide a fix, so we have to live with the work-around.
> 

That is intentional. There are some libio bugs in libc 5 which only
show up when used by libstdc++. That is why there are some, not all,
libio stuff in libstdc++ for libc 5. For libc 6, aka glibc 2, only
one libio file, iogetline.c, is included in libstdc++ since some older
glibc 2 have bugs in iogetline.c.

-- 
H.J. Lu (hjl@gnu.org)