Bug 199055
| Summary: | lang/sbcl: upgrade to 1.2.10 and fix thread concurrency | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jack Carrozzo <jack> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Some People | CC: | marino, spchamp | ||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Bug Depends on: | 204238 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
you should explain why it's valid to disable a build test. My intuition was that getting 1.2.10 into ports for a bunch of bug fixes with the disclaimer that one thing is wonky would be preferable to not upgrading; several tests in sbcl are already disabled for win32 as they are posix-y, so it seemed reasonable to me to disable a test for fbsd as well. I sent a mail to the sbcl maintainers shortly after creating this PR - with any luck they can point me in the right direction to fix the underlying issue, at which point I'll submit a new patch. Building from the SBCL upstream codebase, I was able to build SBCL 1.2.14 on FreeBSD 10.1-STABLE, with both of the :SB-THREAD and :SB-FUTEX options enabled. It seemed that :SB-THREAD build would not complete without enabling the :SB-FUTEX option, additionally. Without the :SB-FUTEX option enabled, the build from 1.2.14 became "stuck" in one of the build-time tests. With the :SB-FUTEX option enabled in addition to :SB-THREAD, the build completed successfully. I've not applied the build to any extensive tests. With apology, it's taken a little while for me to find the bug tracking database, simply to report the matter here. Orthogonally albeit: I'd also enabled the :SB-WTIMER, :SB-THRUPTION, and SB-SAFEPOINT options, in the build. I was hoping that perhaps those might be sufficient for CL+J's Java JNI interface to "work out" in SBCL on FreeBSD. There's something about the interrupts implementation that SBCL inherited from CMUCL, it's denoted at the CL+J homepage. I've yet to be able to test that specific hypothesis with the build, however. Could it be possible to provide those additional options for the port config? I had thought that the matter of the SB-FUTEX option could've represented a request for a new feature to the port's configuration, but I'd noticed that the port was denoted as unmaintained. Of course, SBCL runs with or without multithreading support. I hope it may be as well to mention the :SB-FUTEX workaround here, as a comment to this existing issue tracker item. I'd also mentioned the matter to a social forum, on the Web. I was not then aware of the availability of the FreeBSD bug tracker, here. SBCL is currently at version 1.3.1. If the current port still needs any changes outlined here, could you open a fresh PR with a new patch against the current port? Thanks! |
Created attachment 155036 [details] lang-sbcl-1.2.10.patch This patch against HEAD brings sbcl to 1.2.10 (latest), and reenables the THREADS option. I've fixed the thread concurrency test simply by disabling the single failing test when the system is defined as freebsd; for reference, here's the test I've disabled: --- Test SB-CONCURRENCY-TEST::MAILBOX.MULTIPLE-PRODUCERS-MULTIPLE-CONSUMERS failed Form: (SB-CONCURRENCY-TEST::TEST-MAILBOX-PRODUCERS-CONSUMERS :N-SENDERS 50 :N-RECEIVERS 50 :N-MESSAGES 1000) Expected values: (:RECEIVED . 50000) (:GARBAGE . 0) (:ERRORS . 0) (:TIMEOUTS . 0) Actual values: (:RECEIVED . 49993) (:GARBAGE . 0) (:ERRORS . 0) (:TIMEOUTS . 1). ---