From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124393 invoked by alias); 18 Jun 2018 17:15:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 124369 invoked by uid 89); 18 Jun 2018 17:15:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*r:4.89, upgrading, HTo:U*carlos, Hx-languages-length:1275 X-HELO: albireo.enyo.de From: Florian Weimer To: Carlos O'Donell Cc: libc-alpha@sourceware.org Subject: Re: Future of libio vtable compatibility References: <87h8m41oa0.fsf@mid.deneb.enyo.de> <3a215566-1748-a095-8bfa-c5c1d5017156@redhat.com> Date: Mon, 18 Jun 2018 17:15:00 -0000 In-Reply-To: <3a215566-1748-a095-8bfa-c5c1d5017156@redhat.com> (Carlos O'Donell's message of "Mon, 18 Jun 2018 12:07:32 -0400") Message-ID: <874li0uig3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-06/txt/msg00505.txt.bz2 * Carlos O'Donell: > On 06/15/2018 03:50 AM, Florian Weimer wrote: >> Should we instead remove the compatibility logic altogether? > > The libio vtable internal ABI compatibility has been a real source > of pain over the years, and it has prevented the general cleanup > of the libio code. > I'm inclined to argue that glibc 2.x should remain compatible with > the old internal ABI of the vtables, but that perhaps a future glibc > with a new major version might drop it entirely. But how do we test this? We learned about the incompatibility only because there's an unambiguous error message about it. Remember that none of the affected people tried to report this upstream. The two internal cases we had end up with the users upgrading their obsolete binaries anyway (we didn't get the binaries that reproduced the issue). It almost looks to me as if nobody really wants that level of backwards compatibility. We could require that vtable compatibility requires setting an environment variable in glibc 2.28. This might finally allow us to gather some data. Either nobody needs backwards compatibility, or our backwards compatibility is just too perfect. It's difficult to tell why we don't see more bug reports in this area.