Rask Ingemann Lambertsen wrote:
> So, here is the patch to implement the config.cache file trick: Create a
> config.cache file with all the right link test answers for newlib just
> before running configure, in both Makefile.tpl and config-ml.in. This allows
> sparc-unknown-elf to build libstdc++-v3 with unmodified
> libstdc++-v3/configure.ac. Libgfortran's configure.ac needs just the symbol
> versioning patch ported from libssp. And that's it!
This trick seems plausible to me. Certainly, if it works, it would
simplify development of configure scripts for run-time libraries.
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.
What do you and others think?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
