Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Rask Ingemann Lambertsen wrote:
> On Thu, Dec 06, 2007 at 05:37:01PM -0800, Mark Mitchell wrote:
>> Rask Ingemann Lambertsen wrote:
>>
>>> gcc_cv_have_tls=${gcc_cv_have_tls=yes}
>> How do we get TLS with Newlib on the average bare-metal target?
> 
>    I thought I saw a patch for that going in a while ago, but configuring
> libjava on arm-unknown-elf returns no, so I'll change the cache file
> accordingly.

I have to admit that I'm getting concerned.  The issue Richard has
raised about Cygwin, and the various corner-cases here are making me
think that we're at risk of introducing instability.

I was trying to go along with your patch because it seemed like a
compromise between (a) the top-level patch to make things link (even
though they may not correspond to how the toolchain will be used) and
(b) going backwards (undoing the ability to build various run-time
libraries that the top-level patch added).

I was thinking that a basic cache file would be safe, in the sense that
at least it might accidentally disable a capability or two, but not use
capabilities that aren't there.  But, I'm afraid that we're going to
have a hard time getting it set conservative enough, and that if we do
we're going to miss important capabilities.  I'm afraid that we're
making a relatively large change relatively late in the game.

I think I'd prefer to be more conservative: return to the state we had
with previous releases.  The patch that Richard tested fixes libstdc++
and allows us to revert the various top-level changes.

Then, for 4.4, we can tackle the broad question of how we ought to be
build the run-time libraries for bare-metal.  Maybe configure-time
arguments that let the toolchain link in a representative way for the
target environment?  Or a cache file that contains answers to the
questions the run-time library configury is going to ask?  Or hand-coded
logic like presently used by libstdc++?  Since you have strong opinions
about this, perhaps you could lead this debate.

Would you be willing to go along with that plan?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713