George Koehler <kern...@gmail.com> writes:
> On Sat, 19 Feb 2022 12:29:18 +0100
> Omar Polo <o...@openbsd.org> wrote:
>
>> Hello,
>>
>> please find attached a trivial diff to update lang/sbcl to the latest
>> version, 2.2.1 release the last January 30.
>>
>> The changelog is here: http://www.sbcl.org/news.html#2.2.1
>>
>> `make test' seems just like the current version, I'm typing this mail
>> from stumpwm built with sbcl-threads, and I've also tested a couple of
>> other programs that ends up using various libraries from quicklisp with
>> success.
>>
>> OK/comments?
>
> I have a problem: if devel/capstone/main is installed, then sbcl fails
> to build on powerpc. This happens with sbcl-2.1.11 or sbcl-2.2.1.
>
> sbcl doesn't depend on capstone, and doesn't need capstone to build
> contrib/sb-capstone, but does try to test sb-capstone during the
> build. If libcapstone.so is missing, then sbcl skips the test. If
> libcapstone.so is found, then the test crashes, so the build fails.
> An installed capstone broke sbcl-2.1.11 in the ongoing powerpc bulk;
> I told the bulk to retry sbcl; it succeeded after removing capstone.
>
> contrib might also try to open libmpfr.so (devel/mpfr) and
> libgmp.so (devel/gmp), but both of these are somewhere in sbcl's
> build dependencies.
>
> The fix might be to disable the test, but I have not yet tried this.
> The build failure in sbcl-2.2.1 is,
I can't reproduce the issue on amd64, it builds fine without capstone
and the tests are passing if it's installed.
> Doing 3 pending tests of 3 tests total.
> CORRUPTION WARNING in SBCL pid 41036:
> Memory fault at 0x0 (pc=0xb96bb61c)
> The integrity of this image is possibly compromised.
> Exiting.
> 0: [I*]0x9361bda0 pc=0xb96bb61c {0x50c37288+68a84394} {code_serialno=9970}
> 1: [*] 0x9361bd80 pc=0x50c374b8 {0x50c37288+0230} SB-CAPSTONE::CS-OPEN
could this be an issue in capstone itself on powerpc?
SB-CAPSTONE::CS-OPEN is "just"
(define-alien-routine cs-open int (arch int) (mode (integer 64)) (handle
unsigned :out))
but I don't know how sbcl calls into c. To be fair the `integer 64`
looks wrong, cs_open takes an enum as second argument which should be
just an `int' and the fault at 0x0 could be that 32 bits of mode are
read as the next argument which should be a pointer; I'm probably
talking crap tho. I'll do a build on i386 out of curiosity thought :)
