Re: [RFC] Why do GLIBC tests use internal headers?

[Zack Weinberg <zackw at panix dot com>]

On Fri, Dec 16, 2016 at 11:24 AM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> GLIBC uses internal headers in include/... while building itself.  The same
> internal headers are used when building tests.  This is odd as you'd expect
> it to use an include path that is equivalent to the installed headers for testing.
>
> This causes problems when including headers that are not C++ safe to be
> used by C++ tests - for example include/string.h is used in debug/tst-chk4.cc,
> thus declaring everything in it as C++ with name mangling which causes link
> failures if they happen to be called by the test. I can fix this by adding
> extern "C" {} around any C++ tests, but that doesn't solve the underlying issue.

I posted a patch for this C++ problem a couple weeks ago
<https://sourceware.org/ml/libc-alpha/2016-11/msg01006.html>; it has
so far not been reviewed at all.

> Should we update the include path used in tests to just use the installed includes?

A less-invasive approach might be to give tests their own MODULE_NAME,
which would cause libc-symbols.h to define _ISOMAC and disable most of
itself.  (Right now tests are lumped with 'nonlib', and some nonlib
code does need to see internal declarations.)

zw