From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7615 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: Should we support (not use, support) symbol versioning? Date: Sun, 10 May 2015 11:53:10 +0700 Message-ID: <20150510115310.0e77fd5c@r2lynx> References: <20150510010359.GA8002@brightrain.aerifal.cx> <20150510021838.GM17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1431233542 6606 80.91.229.3 (10 May 2015 04:52:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 May 2015 04:52:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7628-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 10 06:52:22 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YrJDx-0002wQ-T9 for gllmg-musl@m.gmane.org; Sun, 10 May 2015 06:52:22 +0200 Original-Received: (qmail 14044 invoked by uid 550); 10 May 2015 04:52:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14020 invoked from network); 10 May 2015 04:52:19 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20150510021838.GM17573@brightrain.aerifal.cx> X-Mailer: claws_mail Xref: news.gmane.org gmane.linux.lib.musl.general:7615 Archived-At: On Sat, 9 May 2015 22:18:38 -0400 Rich Felker wrote: > On Sat, May 09, 2015 at 09:03:59PM -0400, Rich Felker wrote: > > What we could possibly do, however, is honor the version requested > > whenever the library being searched has version information. This > > would allow third-party libraries that want to use versioning to do > > so while also allowing unversioned libraries to satisfy any program > > or library using them (and work correctly as long as it's using the > > latest version API, just like now). However I'm mildly concerned > > that symbol version tables could get introduced into libraries that > > don't want them (including into libc.so) which would then horribly > > break things, e.g. if any of libgcc.a's symbols were versioned (in > > principle this should not happen, because they're all supposed to > > be hidden, but I'm not really happy relying on that). > > This risk is eliminated just by adding ldso.versym=0; after > decode_dyn(&ldso) in the dynamic linker code, to ensure that any > version tables that happen to creep into libc.so/ldso are ignored. > > Rich Symbol versions were so evil that enforced me to get rid all of them by patching binutils' ld not to support them anymore and every package which fails to build without them. I even have a small base of patches for every package that happen to enforce them. And there are not many of them. No breackage occured in this area after changes. With glibc binaries however not such a nice picture. Simple ones which rely not on glibc's internals probably are worked fine. An advanced ones I happen to work with (nvidia drivers are example) crashed at end when program called exit(), working fine before that. For that little time I instead used another strategy: moved all glibc legacy runtime into chroot with glibc. Now I cannot reproduce this anymore: no such system exists today. I rather think you should not even try to support these. Maybe musl can became the competing libc which will force such recovery changes someday.