Rask Ingemann Lambertsen wrote: > Here's a detail I'm missing. If you configure --with-newlib (or get it > implicitly) and then link with something else when using the toolchain, then > the answers will be wrong, but I don't see how that's any worse than > assuming a set of hard coded link test results.
The issue isn't just Newlib; it's the "BSP" (crt0, system-call implementations, etc.) that you might have in your individual system. Some BSPs add considerable functionality beyond that provided by Newlib itself, and we don't want libstdc++ to detect and rely on that. > How about an explicit option --without-link-tests, --disable-link-tests > or something like that? Most people don't test on bare-metal targets and > won't notice if they break, but given an explicit option to turn off link > tests, you could make it a requirement to test that configure works with > link tests disabled before checking in changes to configure.{ac,in}. That's a reasonable idea, but as Joseph said, for GNU/Linux (and other "hosted" platforms, presumably), we've decided we do need to do links, so on those platforms, --without-link-tests would probably result in broken libraries. > I have a feeling it would be more robust to simulate the link tests > inside the autoconf/libtool macros themselves as opposed to explicitly > avoiding them in each and every configure.{ac,in}. Supply an option > --simulate-link-tests=file_with_results with the default being no and be > happy. We would still need to hard-code things. For example, we want libstdc++ to call functions that are in Newlib (but might not be in other C libraries). So, libstdc++ has to have some way of asking whether the function is in the C library, whether by linking, having the answer hard-coded, or doing some other kind of probe (running nm?). Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713