addpkg(main/sbcl): 2.5.3 #24393
addpkg(main/sbcl): 2.5.3 #24393
Conversation
| +FILE *termux_tmpfile(void) | ||
| +{ | ||
| + return tmpfile(); | ||
| +} |
There was a problem hiding this comment.
I understand the amount of surrounding code is large, making this not immediately obvious, so I will point it out with this comment.
This specific part here, termux_tmpfile() implementation and its call replacement in src/code/fd-stream.lisp, is what partially fixes this issue (meaning, fixes in the manifestation present in SBCL, but does not fix globally for the MRE given in the issue, which in my opinion is probably not possible to fix globally without breaking another software in some way)
- Fixes termux#948 - Partially fixes termux#24176 - Partially fixes termux#183 Previous attempts and progress: - termux@880983e (2016) - termux#7625 (2021) - termux#14435 (2023) This PR mainly implements the package in a termux-packages downstream-oriented way (heavy use of internal termux-packages repository code shared with other termux-packages). There is discussion regarding the upstream-oriented way of implementation from the SBCL side (trying to non-cross-compile while avoiding use of any internal termux-packages repository code) here: https://bugs.launchpad.net/sbcl/+bug/1956852
|
I will merge this in 24 hours if no other problems are found with it. |
|
Thank you for doing this. I had a solution a couple of years ago that I haven't kept up-to-date: It built SBCL with ECL the first time and then with SBCL if SBCL was already installed. The first tries are here: Sorry that I don't have the possibility to look into this in detail right now, but I noticed proot and lots of changes in your solution that I didn't need to do. Maybe those changes are needed to solve the changes in SBCL that caused my solution to fail. Please only see this as a possible source for ideas - your effort is greatly appreciated. |
|
Thank you for the comments metayan! I did consider your version, and it was helpful as a comparison reference to get started, along with others' versions.
Yes, I noticed while reading the PR for your version that the last comment in it by finagolfin before it was closed was:
The proot dependency, and a large number of the other changes that are unique to my version, do that, the implementation of cross-compilability, which is what causes my version to pass the CI workflows in the termux-packages repository without having the same failures here that others' versions had. It's true that this adds a lot of code to the package that is somewhat convoluted, and adds a significant amount of overhead to the build time of the ARM target because of the internal use of |
Previous attempts and progress:
This PR mainly implements the package in a termux-packages downstream-oriented way (heavy use of internal termux-packages repository code shared with other termux-packages).
There is discussion regarding the upstream-oriented way of implementation from the SBCL side (trying to non-cross-compile while avoiding use of any internal termux-packages repository code) here:
https://bugs.launchpad.net/sbcl/+bug/1956852
Preexisting packages that share similar special build dependencies internal to the termux-packages toolchain:
termux-packages/packages/pypy/build.sh
Line 20 in 9286dcb
termux-packages/packages/pypy3/build.sh
Line 11 in 9286dcb
termux-packages/packages/cabal-install/build.sh
Line 12 in 9286dcb
termux-packages/x11-packages/gimp/build.sh
Line 11 in 9286dcb
This is passing 100% of the testsuite on 64-bit ARM Android devices without disabling any tests, and is also passing all of the tests during CI immediately after cross-compilation, except for two tests that only fail in the
termux-proot-runenvironment, and two tests that intermittently fail rarely,read-lineoftests/arena.impure.lisp, andovereager-character-bufferingofstream.impure.lisp. I do not know why they intermittently fail, but in order to avoid a possible CI failure or inconvenience for future builds, I have disabled them here.However, it is currently failing one test consistently,
elfcore.test.sh/elf-sans-immobile.test.shon Android-x86, that would also fail on ARM Android if it were enabled there, but that test is only enabled by upstream for x86 targets, not ARM targets (testsuite toggles between those two variants of the test depending on what featureset the x86 build of SBCL was built with). That is the only failing test I do not yet understand how to fix, so I am disabling it here. Upstream also sometimes disables this test even on x86, depending on a complicated set of factors, as seen in a recent development commit: sbcl/sbcl@b219fb3Upstream does not support 32-bit Android, and when I tried to force-enable the 32-bit Android targets, I could not successfully do it because of the extreme difficulty.
I also have not been able to figure out how to get the docs to successfully build, but the
man sbclcommand does work anyway because thesbcl.1manpage is included in the source archive.@roboticarm2000 @metayan @aadcg @francogrex @SAVITAR-tech-collab If you are still interested in SBCL, I would be interested to know your opinions about this build and whether you have any ideas for additional tests I could check whether it passes beyond the official testsuite.