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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17716 invoked from network); 23 Aug 2023 20:04:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 23 Aug 2023 20:04:53 -0000 Received: (qmail 13637 invoked by uid 550); 23 Aug 2023 20:04:49 -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 13600 invoked from network); 23 Aug 2023 20:04:48 -0000 Date: Wed, 23 Aug 2023 16:04:41 -0400 From: Rich Felker To: Mike Granby Cc: "musl@lists.openwall.com" Message-ID: <20230823200440.GY4163@brightrain.aerifal.cx> References: <20230823132948.GX4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] sizeof(pthread_mutex_t) on aarch64 On Wed, Aug 23, 2023 at 01:57:04PM +0000, Mike Granby wrote: > Yeah, that all makes sense. I suspected that would be the case, but > I figured I'd memorialize the issue in case someone else came across > it. This way, they might at least find it via a search. Just for my > interest, I'm going to have a quick look to figure out why glibc > ends up with the different size on aarch64: It seems like it is the > outlie, although my sample size is not large. Re gcompat, that > didn't fix this particular issue and in any case, I really didn't > like what it did to cmdline in procfs with its shimming, but I'll > certainly keep an eye on its development. Thanks for the prompt > response... Re: gcompat, indeed at present it would not help at all, as all it does is add some extra stuff not already in musl's internal ABI-compat. Part of moving all the ABI-compat stuff to gcompat would be getting rid of the need for the kind of shimming you don't like, and having musl ldso do the work of loading a delegated ABI-compat shared library for executables/modules that need it. Rich