Opened 14 years ago
Closed 7 years ago
#29476 closed defect (wontfix)
sbcl +threads does not compile maxima (snow leopard, x86_64)
Reported by: | daitakahashi | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.2 |
Keywords: | Cc: | easye, gwright@…, waqar@…, KubaO (Kuba Ober) | |
Port: | maxima, sbcl |
Description
SBCL 1.0.48 (64bit) with +thread variant failed to build maxima on Mac OS X 10.6.7 (Macbook Pro, early 2011). However, the SBCL (same version) without +threads can build maxima successfully.
The last some lines of port -d install maxima
are shown below (and build process hung since ldb
was invoked). Thank you very much.
; - Loading source file ; "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_math_maxima/work/maxima-5.24.0/src/init-cl.lisp" ; loading #P"/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_math_maxima/work/maxima-5.24.0/src/init-cl.lisp" ; - Providing system maxima [undoing binding stack and other enclosing state... done] [saving current Lisp image into binary-sbcl/maxima.core: fatal error encountered in SBCL pid 79417(tid 140735075560608): no size function for object at 0x00808f40 (widetag 0x40) scanning space for lutexes... writing 6416 bytes from the read-only space at 0x20000000 scanning space for lutexes... writing 4064 bytes from the static space at 0x20100000 scanning space for lutexes... Welcome to LDB, a low-level debugger for the Lisp runtime environment.
Attachments (1)
Change History (7)
Changed 14 years ago by daitakahashi
comment:1 Changed 13 years ago by nikolaus@…
I think this is more of a SBCL issue rather than macports, since SBCL thread support on OS X is (and has been for while) quite broken. For 64bit OS X it was never supported anyways as far as I know.
comment:2 Changed 13 years ago by easye
Hmm. I run sbcl +threads from MacPorts on x86_64 constantly without seeing problems, although mainly I just compile and test ASDF definitions via QuickLisp to test compatibility, so I would not claim to be stressing SBCL +threads in my usage. But it may be more stable than Nikolaus' comment suggests…
comment:3 Changed 13 years ago by daitakahashi
I am not completely sure if this is a SBCL issue or a problem comes from something different causes. But I would like to follow Nikolaus's comment and disable threads variant for reliability.
Following QuickLisp web-page, I confirmed the vecto
package can be compiled without any problem (threads enabled x86_64 SBCL). So the thread enabled SBCL sometimes works fine, however, it may break down at very stressful condition (e.g., maxima build).
Thank you very much for your helpful comments.
comment:4 Changed 13 years ago by daitakahashi
After some experiments, I found some relationships between the problem and a (path) length of build directory name. I set up two directories,
short
something_very_very_long_directory_name_to_test_if_the_length_of_build_directory_name_affects_maxima_build_process
.
Both of them include vanilla maxima 5.24.0
source downloaded from website, and I tested cd maxima-5.24.0 && ./configure --enable-sbcl && make
.
sbcl @1.0.48_0
successfully built maxima
for both cases, however, sbcl @1.0.48_0+threads
failed at case 2 (no problem was found at case 1). The reason of this odd behavior is still not clear, though, I think this is problematic for macports, which uses automatically generated (sometimes very long) name for build directory.
comment:5 Changed 12 years ago by ci42
Cc: | kuba@… added |
---|
comment:6 Changed 7 years ago by kencu (Ken)
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The particular issue in this ticket is no longer seen with new versions of sbcl.
Complete build log of maxima