This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -ffunction-sections


> > This seems backwards to me; surely we can CHECK_COMPILER_FEATURES
> > without needing a linker, and only CHECK_LINKER_FEATURES needs to be
> > avoided?
>
> As long as one is
>
> 1) using the "C" compiler, not the C++ compiler
>
> 2) using and finding correct binutils and "C" compiler (including all
> necessary libraries and startup files)
>
> 3) not requiring built executables to execute and run
>
> I would assume that even things that required linking could be
> auto-confed. The problem is satisfying the three requirements above in a
> simple and sane way. Thus the current hacks.

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"? 

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?  

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

So why can't there be only the tree as currently exists in 
"configure.target"? Perhaps just made slightly more general to handle cross 
compiles?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]