From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4610 invoked from network); 17 Jul 2023 16:55:43 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2023 16:55:43 -0000 Received: (qmail 7699 invoked by uid 550); 17 Jul 2023 16:55:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 7664 invoked from network); 17 Jul 2023 16:55:40 -0000 Date: Mon, 17 Jul 2023 12:55:30 -0400 From: Rich Felker To: Jeffrey Walton Cc: musl@lists.openwall.com Message-ID: <20230717165530.GL4163@brightrain.aerifal.cx> References: <20230717011758.55d20eae6e60835c5c7fe954@killthe.net> <20230717152103.GK4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl -- FFS get your shit together, please On Mon, Jul 17, 2023 at 12:01:00PM -0400, Jeffrey Walton wrote: > On Mon, Jul 17, 2023 at 11:21 AM Rich Felker wrote: > > > > On Mon, Jul 17, 2023 at 01:17:58AM -0500, Dave Blanchard wrote: > > > There's a lot to like about musl, but damn, there's some absolutely ridiculous aspects also: > > > > > > 1) How in the hell are you going to make a MAJOR change like > > > changing #ifdefs from defined(_LARGEFILE64_SOURCE) || > > > defined(_GNU_SOURCE) to just defined(_LARGEFILE64_SOURCE) in a PATCH > > > level increment, from 1.2.3 to 1.2.4? What the hell is wrong with > > > you? You just broke my entire build! Yet another patch had to be > > > created on my end to UNDO this crazy change; the only alternative > > > was patching half the packages on my system to fix their now-broken > > > build! Do you know NOTHING about proper versioning??? > > > > Our versioning system works like this: in x.y.z, > > > > - increment of x, likely to never happen, would indicate a completely > > different ABI > > > > - increment of y indicates a change whereby programs compiled for the > > new y, even without use of any new features added in new y, may not > > run with an older y. canonical example: time64. > > > > - increment of z indicates a change whereby programs built for the new > > z should still run on older z (modulo any bugs that might be present > > in the older version) as long as they're not using new interfaces > > introduced in the new z. > > > > All of these conditions are assuming the program used the public > > interfaces and did not poke at unspecified internals, etc.; if it did, > > all bets are off and any version change may be fully-breaking to the > > program. > > > > Note that all of these deal with ABI compatibility, not compile-time > > compatibility. > > To play devil's advocate... If a symbol in Musl disappears, then > shouldn't that be considered an ABI break? And then, shouldn't it > require a major or 'x' bump? Only if that symbol is something that can be linked to as part of using the published (via the headers) API. If for example you used __clone, __dl_seterr, __funcs_on_exit, __map_file, __setxid, or any of the other internal interfaces and one of these changed, it would not be an "ABI break". (Note: most of these are hidden nowadays for dynamic linking purposes, but for the sake of this thought experiment you could think of static linking your old .o files to a new libc.a and the same "ABI issues" would apply, without the benefit of visibility protecting you from being able to reference internal things.) > It seems like Musl signed that contract when it first published a > symbol under _LARGEFILE64_SOURCE or _GNU_SOURCE. When the symbol > disappeared using one or the other define, then the contract was > broken. Our _LARGEFILE64_SOURCE explicitly did not/does not use any symbols. It's purely macro-based at compile time. If you're going to jump in and argue about something, at least take the time to check the basics on something like this. Rich