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

[Carlos O'Donell <carlos at redhat dot com>]

On 03/01/2017 01:48 PM, Zack Weinberg wrote:
> 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.

Thanks. Saw that and replied already.

>>> 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?

OK, I just reviewed this on our side.

In RHEL7 (glibc 2.17) we install stdio-lock.h because we need to build
our ancient compat versions of the compiler e.g. GCC-2.95.3:
~~~
# NPTL <bits/stdio-lock.h> is not usable outside of glibc, so include
# the generic one (#162634)
cp -a bits/stdio-lock.h $RPM_BUILD_ROOT%{_prefix}/include/bits/stdio-lock.h
# And <bits/libc-lock.h> needs sanitizing as well.
cp -a releng/libc-lock.h $RPM_BUILD_ROOT%{_prefix}/include/bits/libc-lock.h
~~~

I recently removed this requirement from Fedora and forced the old gcc package
to carry it's own copies of the headers to use during builds.

>>>>> +    $(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?

Yes :-)

>> 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?

It better not matter in this case. We are using it everywhere as our replacement.

-- 
Cheers,
Carlos.