This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] Add IS_IN (testsuite) and remaining fixes.
- From: Zack Weinberg <zackw at panix dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Wed, 1 Mar 2017 13:48:54 -0500
- Subject: Re: [PATCH 4/4] Add IS_IN (testsuite) and remaining fixes.
- Authentication-results: sourceware.org; auth=none
- References: <20170220130342.6373-1-zackw@panix.com> <20170220130342.6373-2-zackw@panix.com> <20170220130342.6373-3-zackw@panix.com> <20170220130342.6373-4-zackw@panix.com> <20170220130342.6373-5-zackw@panix.com> <402fa86b-5738-1749-a515-2e0e6c055bdd@redhat.com> <6157828e-4b05-5261-ea8a-e3a531697d4e@panix.com> <e7bd56e1-845d-52d3-8c8c-8415fa7c6e19@redhat.com>
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