From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9015 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl & proprietary programs Date: Sat, 26 Dec 2015 22:54:59 -0500 Message-ID: <20151227035458.GF238@brightrain.aerifal.cx> References: <20151222222513.10f23f5a@r2lynx> <20151223144852.GR23362@port70.net> <20151224002205.588ac8e8@r2lynx> <20151223174352.GA238@brightrain.aerifal.cx> <20151224015135.34dfe5f4@r2lynx> <20151224120442.04e497db@r2lynx> <20151224051625.GC238@brightrain.aerifal.cx> <20151224104009.GT23362@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1451188519 29263 80.91.229.3 (27 Dec 2015 03:55:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 03:55:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9028-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 27 04:55:19 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 1aD2QO-0007vX-8c for gllmg-musl@m.gmane.org; Sun, 27 Dec 2015 04:55:16 +0100 Original-Received: (qmail 17583 invoked by uid 550); 27 Dec 2015 03:55:12 -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 17563 invoked from network); 27 Dec 2015 03:55:11 -0000 Content-Disposition: inline In-Reply-To: <20151224104009.GT23362@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9015 Archived-At: On Thu, Dec 24, 2015 at 11:40:10AM +0100, Szabolcs Nagy wrote: > * Rich Felker [2015-12-24 00:16:25 -0500]: > > On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote: > > > There is also problem that musl wishes not to be fully glibc compat. > > > Certain libc structs and public structs coming from glibc headers that > > > are not required to be ABI same will be different on musl for > > > performance or optimization reasons, and programs relying on them > > > usually will not be happy. Simple programs probably still will work. > > > > There are no differences for performance or optimization reasons, > > unless you want to count [u]int_fastNN_t which are basically never > > used in public APIs anyway. Otherwise the only differences are that > > musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't > > match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use > > this ABI anymore anyway) and that musl does not copy the > > non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit > > archs (this only affects regexec). > > thread cancellation cleanup abi is different too > (because glibc is broken for async-cancel) > but nobody uses that so it should not be a problem Indeed, I forgot about that because it's not a types difference. I'd thought about possibly trying to support that too, but it looks hard and not worth the effort (or other costs). > the nvidia dso may segfault for many reasons, iirc > the last time we identified that it uses stdio in > a broken way, but there are numerous problems so > a crash should not be a surprise. Indeed, I think we found that it's assigning to stdout, which aside from being utter nonsense (stdout is not even specified to be an lvalue), happens to crash since musl's stdout is const and thus usually in read-only/relro memory. Rich