I am considering putting together a handful of static builds for popular platforms build daily and hosted here – is that something people would be interested in?
I considered static builds to work around the problem of debian shipping a castrated ncurses that doesn’t support mouse wheel up (3 years after ncurses6 was released, unbelievable), but as far as I remember it didn’t work out because ncurses has runtime dependencies or something.
Considering that ncurses is the only “real” dependency, I think it’s not as useful as with some other applications.
There is also the problem that you really want the bundled scripts too, so the best solution would be to lobby distros to package kakoune.
I considered static builds to work around the problem of debian shipping a castrated ncurses that doesn’t support mouse wheel up
The whole ncurses gpm thing is a mess indeed, on Debian and Debian derivatives… additionally it can be annoying to get it building on older distros, which is exactly what bites me sometimes when support clients. Landing on Ubuntu 12.04 or 14.04 isn’t that unusual… even with 12.04 being EOL like last year.
There is also the problem that you really want the bundled scripts too, so the best solution would be to lobby distros to package kakoune.
True about the bundled scripts. I think Kakoune is still moving quick enough getting packagers to support it is tough. But as I am writing this comment, I wonder how much headway we could make with just a snap and a flatpak… Snaps work back to 14.04 Ubuntu at this point.
Kakoune only cares about the relative path from binary to resource files, so it will run happily from a tar.gz expanded anywhere.
AFAIK, the main problem with static linking is that glibc way to get the user name is not compatible with static linking, and warns that it will only work if it can find libresolv.so or something like that.
I assumed static builds would not be useful, until I tried to build Kakoune on a machine with 500MB of RAM.
Heck, since the only dependencies are ncurses and glibc, both of which have pretty solid ABI guarantees, even dynamically-linked builds would be useful. CentOS 7 only has ncurses 5.9, so a Kakoune built on a CentOS VM wouldn’t have mouse-wheel-up support, but for a lot of uses that’d be better than no Kakoune at all.
It might be useful to have a ‘portable’ makefile target that creates a temporary directory, installs Kakoune into it with “make install”, and tars it up.
make PREFIX="" DESTDIR=/tmp/kakoune/ install should do the trick. tar that directory and you will have something that should work everywhere, regardless of the path it gets untared in.
2 Likes
I had to add -lgpm to make the static build work, but even with that going to older Ubuntu distros I end up with issues like this.
I tried re-setting up the locale’s (where already working properly I think) confirmed with:
perl -Mcharnames=:full -CS -wle 'print "\N{EURO SIGN}"'
prints properly.
were you able to fix that issue? I’ve got the same thing on my static build working on these old ubuntu14.04 machines. I can cat a file with clippy’s unicode inside and it renders fine, but he doesn’t render in kakoune. I compiled with a static 6.1 ncursesw.
No, I am really stuck on that issue. 
Wasn’t there something about locale data being moved, or switching to an incompatible format, somewhere between Ubuntu 14.04 and modern times? So a binary statically linked against modern glibc wouldn’t be able to find locale data on an old system, even if locale data works fine for binaries linked with the correctly-archaic version of glibc.
It might be worth trying to statically link MUSL libc rather than glibc, in the hope it’s got a more portable locale-data story.
@Screwtapello confirmed, just as a test I copied my modern /usr/lib/locale/locale-archive to the old machine and it works. Not a real solution but confirms the issue. For now I’m just going to ignore the problem.
That is a great confirmation of the issue at least, thanks for doing the legwork.