This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH] Don't install libio.h or _G_config.h.
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 22 Dec 2017 21:20:05 -0800
- Subject: Re: [RFC PATCH] Don't install libio.h or _G_config.h.
- Authentication-results: sourceware.org; auth=none
- References: <20170828140613.29221-1-zackw@panix.com> <436459cc-2430-d23d-ed85-7b8f1de67651@redhat.com>
On Fri, Dec 22, 2017 at 11:30 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 08/28/2017 04:06 PM, Zack Weinberg wrote:
>>
>> It passes the testsuite on x86_64-linux, but it needs a great deal of
>> additional testing; in particular I'm almost certain I broke the
>> support for old-format (GLIBC_2.0) struct _IO_FILE, which is
>> configured out on this target. Testing this properly would require
>> someone to get their hands on_really_ old binaries, compiled against
>> glibc 2.0, possibly statically-linked-but-using-NSS. Unfortunately,
>> libc.so cannot be expected to be binary identical.
>
>
> elf/tst-audit1 and others break on i386. Usually, this is due to
> dlmopen/stdio sync issues, but in this case, it might be caused by a
> _IO_stdin_used mismatch. For some reason, I don't have debuginfo for the
> inner libc, so this is rather difficult to diagnose. I won't be able to fix
> this before the freeze, I'm afraid.
Understood. Thanks for trying.
> I think we should unify the libio locking first across glibc (aka get rid of
> _IO_MTSAFE_IO). This will reduce the size of the patch a bit.
That makes sense. For 2.27, I suggest we make the installed libio.h
and _G_config.h issue deprecation warnings. I'll send a patch for
that under separate cover.
zw