Roswell installation method fails - externals-clasp dependency archived

[ItsMeForLua]

The ros install clasp command is currently broken for all users due to the externals-clasp repository being archived. This affects many Common Lisp users who expect Roswell integration to work, as it's referenced in various tutorials and documentation.

Current Problem

When users try to install clasp via Roswell:

ros install clasp

They get a segmentation fault during the build process because:

• The build depends on the archived externals-clasp repository
• This repository was archived on June 9, 2024, and is no longer maintained
• The archived code has compatibility issues with current build environments (modern GCC, etc.)

Could the clasp team either:

1. Update documentation to reflect that Roswell installation is currently non-functional and provide clear alternative installation instructions
2. Work with Roswell maintainers to fix the integration (I've filed an [issue] on the Roswell repository about this)

Cross-Reference

I've also filed a detailed technical issue with the Roswell maintainers about fixing their clasp installer scripts. The issues are related but target different aspects of the problem.

Environment

This affects users on modern Linux distributions with current GCC versions, which appears to be incompatible with the archived externals-clasp code from 2019.

---

While not a clasp core issue, this significantly impacts user onboarding since Roswell is a popular Common Lisp installation manager

[ItsMeForLua]

Im in the process of updating roswell's install-clasp-bin.lisp file to use the koga build system.

I got it working for 2.7.0 mostly, but right now I'm in the process of handling the earlier version's build process quarks.
Mostly path issues regarding what compilers are used and where they're found.
It seems the 2.6.0 version only supports clang++?

2.70 seems to be able to handle g++ and/or clang++, but earlier versions seem to be hardcoded, (or is only stable with) clang++(?)

[yitzchak]

We only use clang. Don't use g++. I should add some detection to ensure that someone doesn't attempt that.

[ItsMeForLua]

We only use clang. Don't use g++. I should add some detection to ensure that someone doesn't attempt that.

Aha! That makes sense, I'll update the dependency checks

[yitzchak]

We have to infer the location and details of clang from its proximity with llvm, via llvm-config. Because, for some reason nobody thinks having a clang-config program would be useful. Its very difficult to ensure clang is around without resorting the automake silliness of compiling and executing code fragments.

[ItsMeForLua]

Hey yitzchak, while working on the Roswell script to support Clasp 2.6.0, I ran into a build failure on Linux. It looks like clasps internal build system hardcodes -fuse-ld=gold, which isn't neccesarily bad, but a given installation of the gold linker might not have been compiled with the necessary LLVM plugin support, making it incompatible with LLVM-based builds. Patching the ninja.build script to use lld completely sidesteps the need to verify the user's gold installation and instead uses the linker that is guaranteed to be compatible because it's part of the same LLVM toolchain. As far as I'm aware, at least

To make the installation aligned with roswells "just works" philosophy, I've patched the install script to automatically modify the generated build.ninja file, replacing -fuse-ld=gold with -fuse-ld=lld. This should ensure it uses the linker from the LLVM toolchain that's already a dependency.

Let me know if you have any concerns with that approach.

I'm technically not done with that implementations, but so far the steps to it have demonstrated its feasibility, it does seem promising

[yitzchak]

Was this just 2.6, or 2.7 also?

[ItsMeForLua]

right now my main concern is getting 2.6 to work. I started without touching llvm-config because the resulting errors were useful diagnostics for understanding the build system, now (now im using the config) I'm just on the last hill which is getting the linking order right. Since as you mentioned, there's no clang config, unfortunately. I'm having to manually run nm and grep on .a and .so files just to find the correct linking order, which is tedious, but, it will get me to a proof of concept atleast and then I can improve it all from there.

[ItsMeForLua]

i was hoping llvm-config --libs would show the dependencies, and I thought it would, but I guess not all llvm-configs are packaged in a way we need them to be packaged. I'd prefer not to manually hardcode dependency link order, so I'm gonna have to try and figure out a way to dynamically link in the correct order, while accounting for different toolchain versions.

This might take me longer than I thought it would, but I think it's possible.

[yitzchak]

I suggest focusing on v2.7. There really isn't any reason to use v2.6

[ItsMeForLua]

After some time away, and then coming back to touch base, I've realized I had forgotten the initial objective to use the clasp binaries first, and then to worry about ros install clasp-source after-the-fact.

On that note: I should have the ros install clasp-bin finished within 2 weeks.

[ItsMeForLua]

Update:

Looking at my workload, even with chemistry and mathematics classes, I should have enough time to finish the source install much much sooner.

Especially when we account for Koga