1 |
Hello *, |
2 |
|
3 |
The sbcl upstream only supports glibc Linux systems. Building sbcl uses |
4 |
sbcl binary (which fails to run on musl) to compile sbcl sources. |
5 |
|
6 |
In principle, one can try a workaround: use some other lisp (say, clisp or |
7 |
ecl) as the bootstrap lisp. This way is at best brittle: there is no |
8 |
guarantee that these external lisps will compile the sbcl sources |
9 |
successfully. People say that sometimes this works. |
10 |
|
11 |
No user of musl profiles could successfully emerge sbcl from time |
12 |
-infinity to the present moment. The natural solution is to pmask sbcl in |
13 |
musl profiles. |
14 |
|
15 |
So I've done. But this leads to unexpected consequences. dev-ros/roslisp |
16 |
hard depends on sbcl. ros-meta/ros_core hard depends on roslisp. |
17 |
ros-meta/ros_base hard depends on ros_core. |
18 |
ros-meta/{perception,robot,viz} hard depend on ros_core. Maybe, more |
19 |
packages depend on {perception,robot,viz}, I haven't checked. |
20 |
|
21 |
This means that no user of the musl profiles has ever been able to emerge |
22 |
all these packages (because they did not have sbcl). And all these |
23 |
packages should be pmasked in the musl profiles. |
24 |
|
25 |
Before doing this drastic change I decided to ask for your advice. Should |
26 |
I go forward and pmask them now? Or maybe for some of them the dependence |
27 |
on sbcl can be made optional, and it would be sufficient to use.mask such |
28 |
an option name? Or maybe roslisp can use some other lisp instead of sbcl? |
29 |
|
30 |
Andrey |