This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] Fix / clean-up config vs crosses (2/n)
Hi,
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.
Yeah, now I remember why Joseph introduced AC_TRY_COMPILE_OR_LINK, for
some C99 functions... I think we already said that the practice isn't
really nice, for users too, not just for our configury... Anyway, can I
ask to you and Joseph to double check whether those
declared-but-not-defined tricks are common also for functions like
writev, pool, LFS I/O... Certainly you know those systems much better
than me...
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.
Yeah, I also fear that, I would really like to accomplish as much as
possible without linking.
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.
Ok...
Thus, while waiting for more feedback, I will probably apply the
AC_CHECK_HEADERS bits, which seem safe...
Paolo.