[v3] Fix / clean-up config vs crosses (2/n)

[Mark Mitchell]

Paolo Carlini wrote:

> this is the 2nd installment, which I'm finishing testing and mean to commit in 1-2 days. Please have a look. Basically, I'm doing 2 rather simple things: 1- Some existing tests can be changed to use TRY_COMPILE and thus run unconditionally; 2- Different sets of AC_CHECK_HEADERS are scattered around in the configurations for native and for crosses, I think a common set can be safely run unconditionally.

Thanks a lot for working on this!

My only comment is that AC_TRY_LINK is a bit more accurate than 
AC_TRY_COMPILE, so you might want to consider those changes carefully. 
I can imagine systems where things might be declared in headers, but not 
defined in the corresponding libraries.  For example, with uClibc, you 
can configure the library not to include various things, but I don't 
think the headers change.  The same thing is true on VxWorks and quite 
possibly in other RTOS environments.  So, something like:

!     AC_TRY_COMPILE(
         [#include <sys/uio.h>],
         [struct iovec iov[2];
          writev(0, iov, 0);],

is now only going to check that writev is declared, not defined.

Of course, as we discussed previously, some people (as I understand it) 
want to run the configure tests before having everything in place to be 
able to link.  Clearly, there's a conflict between these two needs, and 
  I'm not sure how best to resolve it.  I think it logically makes sense 
for libstdc++ configury to be able to assume that it is allowed to 
compile and link C programs, since we build libstdc++ atop the C library 
-- but I gather that will disrupt some build procedures.

A possible compromise, if this becomes a problem in practice, is 
configure options that allow you to say, for example, that you do not 
have writev.  Then, if you have a C library that has the functions 
declared in the headers, but not defined in the library, you can tell 
libstdc++ not to use them.  Error-prone, but workable.

Thanks,

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