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=-0.0 required=5.0 tests=NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3932 invoked from network); 25 Feb 2021 16:41:24 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 25 Feb 2021 16:41:24 -0000 Received: from mx.sdf.org ([205.166.94.24]) by 1ess; Thu Feb 25 11:36:28 -0500 2021 Received: from [192.168.1.11] (ip72-208-180-113.ph.ph.cox.net [72.208.180.113]) (authenticated (0 bits)) by mx.sdf.org (8.15.2/8.14.5) with ESMTPSA id 11PGaD1q001810 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128 bits) verified NO) for <9front@9front.org>; Thu, 25 Feb 2021 16:36:23 GMT To: 9front@9front.org References: <15F8DE7C4A612A93BF917BA8798997A1@eigenstate.org> From: Aaron Message-ID: Date: Thu, 25 Feb 2021 09:37:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <15F8DE7C4A612A93BF917BA8798997A1@eigenstate.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized engine method-aware interface Subject: Re: [9front] [Patch] APE changes (2019 Lufia patches) Reply-To: 9front@9front.org Precedence: bulk On 2/24/21 7:21 PM, ori@eigenstate.org wrote: > Quoth ori@eigenstate.org: >> We'd need these for all the other archs that we >> support, otherwise ape will fail to build on >> anything other than 386 and amd64. >> If I could do do things over again I would simply remove those changes. I removed most of the architecture specific changes, and in doing so removed the context for the inclusion of the `_apetypes' file. A mistake on my part. >>> +#endif >>> diff -r bfe93397b157 sys/include/ape/pthread.h >> >> Would you be willing to split the pthread changes >> out? it's a lot of tricky code, and it's rather >> hard to review. I can split out the pthread changes and supply that diff later today. >> >> Same for the cpp include_next, which I'd rather >> not commit if we can get away with it (ie, what >> software is relying on that nonstandard extension, >> and is it a big change to fix the software, and >> maybe even upstream the change?) >> I am more than willing to supply the include_next changes separately, but if no one wants them imported that is fine as well. > > And, again -- can you let me know what programs this > enables, and whether they've been tested with this > patch on 9front? > I never went as far as the original intent, being Torvalds git, instead focusing on the dependencies: curl, expat, zlib, and libressl. There are separate patches specifically for libressl to build, but those patches were insufficient for me on 9front. I did manage to get libressl to build but curl still had issues with TLS addresses. At the time I chose to see the failure as isolated to the libressl patches. The other packages worked without modification. As it stands it is my intention to submit separate diffs for pthread, include_next, and a third for the remainder (excluding _apetypes). If this proposal is unacceptable please let me know. If anyone would rather see further testing then that is perfectly fine as well.