On Tue, 27 Nov 2007, Mark Mitchell wrote: > In any case, I think this is something that ought to be decided as a > global policy for GCC and its run-time libraries, not something that > differs between ports. In particular, if run-time libraries are allowed > to depend on linking in their configure tests, that's something everyone > should know.
For GNU/Linux, we decided some time ago that libstdc++ configuration would require link tests in order to identify the precise functions available in that particular multilib's libc version and configuration (depending, for example, on how uClibc is configured). It is, after all, the case that you cannot create a proper libstdc++ shared library on a glibc system without linking it against a shared glibc so that it is bound to the right symbol versions in that glibc (static libraries do not generally remain compatible across glibc upgrades where symbols the static libraries use get new versions), and so you must already have a C library you can link against in order for libstdc++ to build, so you may as well use that library at configure time. Some other targets similarly do many link checks in libstdc++-v3/crossconfig.m4. If only static libraries are being built, it may be possible to build them without linking, and in such cases it may be possible to define a generic set of libc symbols considered to be present, as libstdc++-v3/configure.ac does with newlib. -- Joseph S. Myers [EMAIL PROTECTED]
