From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13663 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Symbol versioning approximation trips on compat symbols Date: Mon, 28 Jan 2019 11:17:32 +0200 Message-ID: <20190128111732.26097820@vostro> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> <20190124110931.GU21289@port70.net> <87sgxi718r.fsf@oldenburg2.str.redhat.com> <20190127040424.GA23599@brightrain.aerifal.cx> <20190127093650.GB30123@example.net> <87bm41xpce.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="21873"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com, u-uy74@aetey.se To: Florian Weimer Original-X-From: musl-return-13679-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 28 10:17:52 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1go338-0005Ze-TG for gllmg-musl@m.gmane.org; Mon, 28 Jan 2019 10:17:50 +0100 Original-Received: (qmail 20108 invoked by uid 550); 28 Jan 2019 09:17:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20090 invoked from network); 28 Jan 2019 09:17:48 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OPgwrc+Us3o22TtTq50aptpseho3aIwTFOcw49K6pio=; b=RJyW5muc9fURq+WfKkef9UjacKkLm/1YN/hRYj2szzsb5VcUsTOQHul8YgtPzquEAr V+2zvodzLNUpxnLQ47ufA2qX0nQEcisoLIrPi2AdD57mvBFYIWe+whlPQeRJZ+cLVY9R K1eiWe1a42nwhm4wnvJeXoibCKZcnpVzkqZdSlnDQWnHatkyRIDF9/VAtcoNoUPRJNqx tOh2NLlPGyzITd1xOCg+QoY0zICIV/A+WEiY30VYITlG31XEAG6vltJAoaQww9XGnkYP unl9soQRr96+81A1bIbdiF6o+pL2JSKSDSU+1DyKv81BT1zn2QwfqHKXZ7iDHFT6q0KC pcaw== X-Gm-Message-State: AJcUukeoJC+GH8RMy3hvMGZQQoSOisJ2V02MItQBokqXh18CXdUKC/H+ OASLelTo8/Gu6Eux39pxFwI= X-Google-Smtp-Source: ALg8bN7sEsmzDKzZHPwJt1i5rzgXsdxfNQvg8TrRxlXo+/8b7Duf6airFQbEvC6grfQZC4dsUv2csg== X-Received: by 2002:a19:a40f:: with SMTP id q15mr15679119lfc.4.1548667056626; Mon, 28 Jan 2019 01:17:36 -0800 (PST) In-Reply-To: <87bm41xpce.fsf@oldenburg2.str.redhat.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:13663 Archived-At: On Mon, 28 Jan 2019 07:34:25 +0100 Florian Weimer wrote: > * u-uy: > > > On Sat, Jan 26, 2019 at 11:04:24PM -0500, Rich Felker wrote: > >> For what it's worth, compat symbols would have let us remove > >> symbols that shouldn't have been put in musl, such as lchmod > >> (which confuses broken apps which wrongly expect that, if it > >> exists, it should work) > > > > For what my integrator perspective is worth, exposing brokenness > > instead of catering for it is a Good Thing. > > > > Feature detection is one of the typical areas being messed up, in > > numerous softwares. > > > > Thanks musl for exposing the pitfalls and forcing upstreams think > > better. > > As I explained, precisely that is not the case because the main musl > user, Alpine Linux, builds musl with a broken toolchain that is not > properly targeted to musl's features. I think the official musl > instructions have the same result. I remember trying to build tool chain with symbol versioning disabled. However, it did not work out. It's long time ago, and I don't remember exacts (if it was build failure, or run time failure). Could be that the symbol version extension stop working failing build of various software. Or maybe it was that the libgcc builds with symbol versioning enabled/disabled are not compatible, so we would also lose glibc compatibility if we disabled. But what I remember that it did not work at all. Perhaps it was just broken gcc version or something like that. In any case, I came to conclusion that toolchain with symbol versions disabled on linux did not fell like first class citizen. Or maybe I just messed up something. Has anyone built toolchain with symbol versions disabled from recent binutils+gcc and used that to build a non-trivial amount of software? Say 100+ packages? Timo