-ffunction-sections

[Tony Bryant]

On Fri, 14 Jun 2002 00:38, Benjamin Kosnik wrote:
> Cross compiling implicitly assumes newlib. If your goal is to build a
> compiler for sh-linux on x86-linux that uses specific version of glibc,
> you have to have a more elaborate configure command than just
> --target=sh-elf.

I'm not bulding sh-linux. glibc doesn't ever touch my sh processor. I 
building sh-elf. My sh-elf system is newlib based (like mingw32)

> What are you trying to do, what have you tried, and where did the
> documentation fall down?

I was working through the (admittedly currently theoretical) possibility of 
building libstdc++ natively on my one of my sh-elf (NOT sh-linux) systems 
that uses newlib. 

To clarify the two case I'm considering:

1) on my linux box:
 ../gcc/configure --target=sh-elf --host=i686-pc-linux-gnu 
--build=i686-pc-linux-gnu  

2) on my sh-elf (i.e newlib based sh-elf box - not sh-linux)
 ../gcc/configure --target=sh-elf --host=sh-elf --build=sh-elf 

But the above is only an example of what can go wrong with the current 
configure setup - i.e. the above two cases produce subetly different 
libstdc++.a outputs - since 

1) picks config/os/newlib (correctly) 
2) picks config/os/generic (incorrectly)

But as I say this is not the specifically the concern. I more concerned with 
the maintenence issues of having the manually setup cross compile portion in 
configure.in. The above being an _example_ of a snafu caused by it.

To clarify my original point:

I see no reason to have the separate branch in configure.in especially for 
cross compilies. There is nothing lacking in xgcc, its target specific C 
libraries, its target specific headers, or its ability to link, so the 
existing (non-cross) configure script portions could easily be made general 
enough enough to handle both native and cross cases.

Please correct me if I'm wrong.