Problem with glibc-2.1.3 and gcc-2.95.2 -ffunction-sections

[Graham Stoney]

Hi Ulrich,

greyham@research.canon.com.au (Graham Stoney) writes:
> I've just run into some grief cross-compiling a simple hello world program
> statically linking against glibc-2.1.3 cross-compiled using gcc-2.95.2 with
> -ffunction-sections & -fdata-sections and the binutils-000330 snapshot
> configured for a powerpc-linux target.

Ulrich Drepper writes:
> It is not necessary to use these options.  They are useful only for
> statically linked applications and the sources are already structured
> so that the least possible code is linked in the application.
> Otherwise there wouldn't be thousands of files in the sources.

My application is statically linked, and there are a number of functions
dragged in which don't get called. You're right that the sources are
structured to exclude most unused functions, but it's not exhaustive.

One example is malloc_stats in malloc/malloc.c. Breaking up malloc.c manually
would be nasty because of all the statics, whereas -ffunction-sections would
achieve the same result automatically.

A trivial "int main() { return 0; }" statically linked & stripped from
powerpc-linux-gcc 2.95.2 with glibc-2.1.3 is 234K, largely because all the
following get pulled in:

    libc-start.c:__libc_start_main	calls	exit.c:	 exit()
    exit.c:	 exit()			calls	malloc.c:free()
    malloc.c:	 malloc_stats		calls	printf.c:printf()

Hence, my statically linked C++ application program which never even calls
printf gets it anyway.  Besides, -ffunction-sections shouldn't cause breakage,
even if unnecessary. I'll take Geoff's advice and try to see where it's dying.

Thanks for the response. I went to your talk at the Sydney Linux expo; was
very interesting. Keep up the good work!

Regards,
Graham