[PATCH 4/4] Add IS_IN (testsuite) and remaining fixes.

[Zack Weinberg]

On Wed, Mar 1, 2017 at 1:17 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/27/2017 08:34 AM, Zack Weinberg wrote:
>>
>> I'm going through your low-level comments now; here are a few notes.
>> I'll post a revised patch later today, or tomorrow.

FYI, a lot of the changes you requested got reshuffled into the
preparation patchset I posted this morning.  I have revised the core
change as well but I'm not going to post it until I do the built
artifact comparison, which I may not have time for till the weekend.

>> What I'm going to do is remove the internal-use-only _IO_* macros to
>> include/libio.h, and invent a new macro _IO_lock_t_defined which all
>> versions of stdio-lock.h will define; libio.h will define the stub
>> _IO_lock_t if that macro is not defined, with a comment explaining that
>> this is only relevant when building glibc itself.  Then there will be no
>> uses of _IO_MTSAFE_IO in public headers, and it won't be necessary to
>> undefine it in include/stdio.h.
>
> OK, make sure we don't break old libstdc++ here, which I vaguely remember
> was tied into this macro and stdio-lock.h.

I'll do some archaeology and find out for sure, but I _think_ that has
not been relevant since before libstdc++-v3 (so we're going all the
way back to the EGCS period).  Moreover, we do not install
stdio-lock.h; any external software that attempts to define
_IO_MTSAFE_IO without supplying a definition of _IO_lock_t will fail
to compile, and do we really want to support software that provides
its own definition of _IO_lock_t?

>>>> +    $(tests) $(tests-internal) $(xtests) $(test-srcs))): \
>>>> +   $(objpfx)libpthread.so \
>>>> +   $(objpfx)libpthread_nonshared.a
>>>
>>> Why doesn't this use $(shared-thread-library)?
>>
>> It was that way when I got here, and I don't actually see any code that
>> *sets* $(shared-thread-library) anywhere in the Makefiles, so I can't
>> confirm that it'd be the same thing.
>
> sysdeps/nptl/Makeconfig:

Oh ghod, you mean to tell me subdirectories can have Makeconfig fragments too?

> shared-thread-library = $(common-objpfx)nptl/libpthread_nonshared.a \
>                         $(common-objpfx)nptl/libpthread.so

That's in the opposite order from the opencoded sequence in
nptl/Makefile.  Are we sure it doesn't matter?

zw