Re: [9front] [Patch] APE changes (2019 Lufia patches)

[Aaron <bsdsm@sdf.org>]

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.