On Sat, 3 Dec 2022, Haelwenn (lanodan) Monnier wrote:
Well Alpine is using the ecl route:
https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD
And GNU GuixSD is using the clisp route but per the comments ecl would be
better:
On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote:
> [2022-12-02 05:11:15+] Andrey Grozin:
> > In principle, one can try a workaround: use some other lisp (say, clisp or
> > ecl) as the bootstrap lisp. This way is at best brittle: there is no
> > guarantee that these external
[2022-12-02 05:11:15+] Andrey Grozin:
In principle, one can try a workaround: use some other lisp (say, clisp or
ecl) as the bootstrap lisp. This way is at best brittle: there is no
guarantee that these external lisps will compile the sbcl sources
successfully. People say that sometimes this
On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge wrote:
>
> Andrey Grozin wrote:
> > This means that no user of the musl profiles has ever been able to emerge
> > all these packages (because they did not have sbcl). And all these
> > packages should be pmasked in the musl profiles.
>
> Is the last
> On 2 Dec 2022, at 19:28, Peter Stuge wrote:
>
> Andrey Grozin wrote:
>> This means that no user of the musl profiles has ever been able to emerge
>> all these packages (because they did not have sbcl). And all these
>> packages should be pmasked in the musl profiles.
>
> Is the last
Andrey Grozin wrote:
> This means that no user of the musl profiles has ever been able to emerge
> all these packages (because they did not have sbcl). And all these
> packages should be pmasked in the musl profiles.
Is the last sentence actually true?
Shouldn't only ebuilds with actual
> The sbcl ebuild from the Gentoo tree is useless on musl. And hence it
should be masked. Otherwise somebody would think that [s]he can simply
emerge sbcl on a musl profile, and will be disappointed.
Ah, I see. That makes sense, and I think I can just unmask it in my
custom musl profile.
Thanks!
On Fri, 2 Dec 2022, Tom Gillespie wrote:
For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries.
For the record I've had sbcl building and running on musl for months
without issue (at one point I even had static linking working). You
have to cross compile a musl version and then side load the binary
instead of using one of the distributed binaries. See
On Fri, 2 Dec 2022, Sam James wrote:
If the dependencies are optional (at least for some), we should indeed
(package.)use.mask sbcl on musl to reduce the damage,
then package.mask the remaining unconditional reverse dependencies.
But I cannot do these this myself. I use neither musl nor ros. I
> On 2 Dec 2022, at 05:11, Andrey Grozin wrote:
>
> Hello *,
>
> The sbcl upstream only supports glibc Linux systems. Building sbcl uses sbcl
> binary (which fails to run on musl) to compile sbcl sources.
>
> In principle, one can try a workaround: use some other lisp (say, clisp or
> ecl)
Hello *,
The sbcl upstream only supports glibc Linux systems. Building sbcl uses
sbcl binary (which fails to run on musl) to compile sbcl sources.
In principle, one can try a workaround: use some other lisp (say, clisp or
ecl) as the bootstrap lisp. This way is at best brittle: there is no
12 matches
Mail list logo
