The conditions for inhibit_libc to activate (i.e. for library headers to be absent) are IMO a bit too automatic and the effect is too subtle and serious in some situations. For example, if you pre-install target headers in $target_header_dir, gcc will find them and use them, but still inhibit_libc is activated unless you also specify the location using --with-headers! That by itself is certainly fixable (patch forthcoming changing the default if headers are found in $target_header_dir"; i.e. if stdio.h is present).
However, IMHO inhibit_libc should be better controlled explicitly (by, say, --disable-libc-use or --enable-build-from-scratch or just --without-headers aka. --with-headers=no). A hard configure-time error would then instead be emitted if something is otherwise just missing and unspecified at configure-time, instead of the silent functional difference we have now. How do you feel about this? *Someone* also has thinks along these lines: there's this comment above the stmp-fixinc rule in which there's a late abort when system headers aren't accessible: "FIXME: abort unless building --without-headers would be more accurate and less ugly". The ill effects of inhibit_libc to which I was alerted, is when conditions are otherwise right for the ELF program-header entry PT_GNU_EH_FRAME to be generated by the linker and the library function (glibc et al) dl_iterate_phdr to be used (let's call this mechanism "eh-phdr"). Then, inhibit_libc forces EH tables to be registered explicitly using __register_frame_info (or .._bases; let's call this "eh-registry") instead of relying on eh-phdr. While that may seem pretty innocent, it causes a (one-way) compatibility barrier: exceptions passing through programs and libraries relying on eh-phdr are not caught by libraries (really: libgcc_s.so.1) built with inhibit_libc. (One-way, because a eh-phdr-supporting libgcc_s.so.1 will work with both eh-phdr and eh-registry libraries and programs.) Further details with the patch. brgds, H-P
