On Fri, 19 Apr 2024 06:24:48 +0200, Sebastien Marie wrote: > > Kirill A. Korinsky <kir...@korins.ky> writes: > > > Greetings, > > > > I've encountered an edge case with update of sbcl which lead to broken > > stumpwm. > > > > My stumpwm configuration uses mpd modules which requires sb-bsd-sockets, so > > after update of sbcl... it was broken. > > > > To overstep that issue I must rebuild stumpwm because it is saved image > > which includes sbcl which was used when it was build. > > > > To avoid such issue in the future I suggest to add a note inside lang/sbcl > > that after update x11/stumpwm should have increased revision. > > > > I haven't found any other port which depends on lang/sbcl. > > I commited a REVISION bump to x11/stumpwm (REVISION starts at 0). > > if I properly understand the problem, it is due that you are using both > stumpwm (compiled with older sbcl compiler) and sbcl parts (for a mpd > module), and the version mismatches. > > For now, bumping stumpwm is the simpler, but I wonder if it would be > possible to use stumpwm somehow from source and let's sbcl compilation > to refresh the fasl files if updated. Timo, any idea ? >
Well, I see another way to fix this issue by load all available .fasl files from sbcl which was used to build it, before it had saved image. A bit ugly. Anyway, stumpwm has one more issue which is triggered by upgrade when embeded version of sbcl is changed. It won't start with complains regarding missed version of .fasl files which was created from user's configuration. When configuration is simple, it won't be reproduced, but as soon as user start to use modules, the hell begins. That can be addreses by enabling global cache which seems to be disabled. -- wbr, Kirill
