-ffunction-sections

[Tony Bryant]

On Thu, 13 Jun 2002 07:26, B. Kosnik wrote:
> > If we assume there is a usuable linker and C libraries handy (why are
> > this not current assumptions?), then I wonder what the purpose of the
> > whole "if cross compiler branch"?
>
> Umm. glibc != newlib.

Where does glibc comes into it? glibc is only used for linux native gcc 
compiles. when building a cross libstdc++ - this compilier _doesn't even get 
run_.

Umm, native (i686-pc-linux-gnu) gcc uses: 
	/usr/lib/libc.a
	/usr/include/*.h

sh-elf-gcc uses newlib/whatever you have installed in: 
	/usr/sh-elf/lib/libc.a
	/usr/sh-elf/include/*.h

Where's the conflict? Where's the problem? Is it too much to ask that
when building a cross version of libstdc++, that one has a cross compiled libc
and headers appropriate for that libc installed in /usr/sh-elf/* ? 

Its not even hard to arrange - its as simple as bunging newlib in the source tree.

>
> > Surely exactly the same build should be produced, if I build libstdc++
> > on my native sh-elf machine vs building it on my linux box with my
> > cross sh-elf tools?
>
> No. See above.

1) The same headers are installed in /usr/sh-elf/include vs. my sh-elf's 
systems /usr/include
2) The same libc.a and crt0.o is installed in /usr/sh-elf/lib vs. my sh-elfs' 
system /usr/lib
3) sh-elf-gcc produces the same output vs. my sh-elf's native gcc.

Assuming that all of the above are correct (and why not?), then what else can 
possibly mandate a different building libstdc++ differently?

>
> > It doesn't happen at the moment, native tools give me
> > config/os/generic, cross tools give me config/os/newlib.
>
> ... right.

WRONG. It shouldn't matter what the build machine it, what is being built 
shouldn't subtely change.