Link tests after GCC_NO_EXECUTABLES

Rask Ingemann Lambertsen
Wed Dec 5 17:22:00 GMT 2007

On Sun, Dec 02, 2007 at 01:10:44PM -0800, Mark Mitchell wrote:
> My only concern with this approach is that Newlib might not be entirely
> consistent across configurations and architectures.  The libstdc++
> approach presumably entails some manual verification of each function's
> presence or absence; before we claim that "Newlib has foo" someone
> verifies that.  I don't know if this is a problem in practice.
> For example, these lines seem like things that might vary.
> > +have_fpsetmask=${have_fpsetmask=no}
> ...
> > +have_sync_fetch_and_add=${have_sync_fetch_and_add=no}
> I suppose we could solve that problem, if it arises, with different
> config.cache files for different targets.  Perhaps it would be best to
> generalize this by adding a top-level --with-target-lib-cache= option,
> and then, if that's not present, and $with_newlib is set, passing in the
> Newlib cache that you have?
> That would give people a way to say that for their particular RTOS
> and/or C library the following functions are available.
> In theory, at least, we might also have differences between multilibs.
> It Would Be Nice to be moving GCC in the direction of allowing different
> multilibs for different operating systems and/or C libraries.  So, I
> suppose the all-singing, all-dancing version of this would be some
> option that allows you to specify a cache file per multilib.  But, I
> think that could be left for later.

   I think it wouldn't be all that difficult. The top-level configure could
try to append the target name to the default config.cache and use that as
the default for the --with-target-lib-cache= option. The multilibs are
handled by which could try to append the multilib name and see
if that file exists, and if not, just use what was passed down from the top
level. Less than twenty lines of code on a good day.

Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

More information about the Gcc-patches mailing list