3 ms·
As far as I know, TUI is the only way to build a statically linked app that can be controlled with a mouse. If you're running in a terminal that supports sixel,
by apitman 2y ago
As far as I know, TUI is the only way to build a statically linked app that can be controlled with a mouse. If you're running in a terminal that supports sixel, that covers a huge class of apps. And you get lots of bonuses like excellent cross platform support and running over a network. It's honestly a compelling platform even without the nostalgia factor.
- actionfromafar 2y agoInteresting... never thought of that angle. Mouse control is pretty important.
- kragen 2y agoi think you are probably going to be a sad panda if you are running sixel apps over a network. vnc is passable, xpra is excellent inspired by your implicit challenge, i just compiled a statically linked app that can be controlled with a mouse on amd64 debian, which is at http://canonical.org/~kragen/tmp/static-μpaint http://canonical.org/~kragen/tmp/static-μpaint (2.3 megabytes, but remember that this is just code some random stranger on the internet linked for you to download and run, much like a random npm module). it was a little harder than i expected, but not really very hard. with respect to its staticness, i did get these warnings: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking but those are from functions buried deep in xlib that i may not actually be using. if you do dare to run my executable on your system, i'm interested to hear whether it works and what version of glibc you're using (i'm on 2.36-9+deb12u7) the program is my example paint program, source code in https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpaint.c https://gitlab.com/kragen/bubbleos/blob/master/yeso/%CE%BCpa..., explained line by line in https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.md#extended-example-%CE%BCpaint https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.m... the compilation command line was cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.o \ -L. -lyeso-xlib -lX11 -lXext -lpng -ljpeg -lm -lbsd -lz \ -lxcb -lX11 -lXau -lXdmcp -o μpaint which i was later able to reduce to cc -static -Wall -Wno-cpp -g -Os -I. -std=gnu99 μpaint.c \ -L. -lyeso-xlib -lXext -lX11 -lxcb -lXau -lXdmcp \ -lpng -ljpeg -lm -lbsd -lz -o μpaint and you should be able to build it from source if you clone my bubbleos repo and run `make` in the yeso directory. `make` will build a dynamically linked version, but the compilation command line above will build a static one instead this is using my minimal gui library `yeso` but i'm pretty sure the same approach would work for things like fltk which are designed for static linking. maybe it would work with more expansive libraries like gtk too
- apitman 2y agoWorked for me (glibc 2.40)! I'm honestly surprised (and impressed). Every time I've tried to statically compile a major glib project like X11, the answer the internet has given back is "don't do it". In terms of practicality, what would the runtime requirements of this be? Obviously compatible glibc, but also compatible X api? Though I'm assuming that hasn't changed much in years.
- kragen 2y agothank you! i very much appreciate the information the x11 library doesn't use glib; maybe you meant 'a major glib project like gtk' this binary requires neither compatible glibc nor compatible x api, because it's statically linked. (i just tried it in a chroot with neither glibc nor any x api installed.) it does require a compatible x protocol, including, in particular, the shared memory extension, and yeso also (rather nonportably) assumes that the server's pixel format is 32-bit bgra (i.e. little-endian argb, with the blue byte first). so it won't work over a network (but works fine talking to a local vnc server which can then talk over the network), it won't work in a 16-bit video mode (unless you interpose vnc or something), it won't work in a paletted video mode (ditto), and it won't work in a monochrome video mode. but i don't think it will have any software incompatibilities with any x-windows server from the last 30 years or so the procedure for setting up the testing chroot was to build a static μpaint as above, install the debian `bash-static` package, and: : yeso; mkdir chroot : yeso; cp μpaint /bin/bash-static ~/.Xauthority chroot/. : yeso; XAUTHORITY=/.Xauthority sudo chroot chroot /bash-static bash-static-5.2# it's really a very bare chroot, with very little of the usual unix amenities: bash-static-5.2# ls bash-static: ls: command not found bash-static-5.2# echo * bash-static μpaint bash-static-5.2# echo /* /bash-static /μpaint bash-static-5.2# echo /.* /.Xauthority bash-static-5.2# cd .. # this does nothing bash-static-5.2# echo * bash-static μpaint bash-static-5.2# ./\316\274paint # bash defaults to not supporting utf-8 at this point the program opens a window and i can run it, painting in the window with the mouse, until i close the window X connection to :0.0 broken (explicit kill or server shutdown). bash-static-5.2# echo $DISPLAY :0.0 bash-static-5.2# exit : chroot; this suggests that in fact it does not use getaddrinfo() or dlopen(), for which the linker warned me it would need to have the corresponding glibc version installed at runtime; as you can see, no glibc version at all was installed at runtime, nor any /etc, /dev, /proc, /bin, /usr, or /home. just three files it took me a while to figure out how to get it to find the xauth file correctly; it doesn't use $HOME or /etc/passwd