hum interesting...<esselfe> I might post on the forums for this... In Linux, what's an overview of source code support for statically linked executables and their dependancies? ie a static coreutils or some very early GUI disk usage visualizer like baobab requiring some old GTK? Is --enable-static and --with-DEPNAME=/opt/lib a fully implemented practice/strategy? Would /static be considered FHS-wise?
<mjg> i thought static compilation is pretty much dead on linux
<Brain> you'd think
<Brain> but have you ever heard of AppImage?
<esselfe> I know size and update wise it's not ideal, but some lower-level functionalities would be a safe last-resort
<heat> glibc killed it
<esselfe> yes this happened, and glib-2 does it too, so I plan on some fallback here ^^
<heat> it being bloated + poor static linking support + distros not including libc.a by default absolutely murdered static linking
<esselfe> I'm on a source-based distro here (feasible recompile flagging), but it's so true...
<heat> I didn't quite understand what you're trying to do?
<esselfe> now I always recompile glibc from chroot held by an auxialiary/minimal OS I rebooted to ^^
<heat> if you're trying to use static linking only to build an autotools program you can generally do --disable-shared
<heat> mostly works, some functionality might be disabled because of it though
<esselfe> heat: _everything_ could breaks again, with these spurious "unstable glibc-2.N/gcc-7.1.0" bugs showing more and more, I want a static-wise strategy
<heat> static wise strategy?
<esselfe> good idea, I'll read on it
<esselfe> I don't want _any_ library update triggering any errors anymore
<heat> that's why package managers exist then
<heat> if you limit yourself to static linking there's a lot of functionality that's disabled because of it
<heat> i.e being possible to run a game on either mesa's libgl or amd/nvidia's libgl
<esselfe> even a glib-2 update broke m4/autoconf/automake/autogen (autogen configure: "/usr/share/aclocal/glib-gettext.m4: error, will not redefine glib_DEFUN")
<heat> which distro are you running
<esselfe> I don't want to put everything static... I want a very old baobab version and some ls/cp/mv/rm be available using 'export PATH=/static/bin:$PATH' ... my distro is Lunar-Linux
<esselfe> btw export is a bash builtin
<heat> oh okay, so you want like a small fallback user-space in case something breaks?
<heat> you can get yourself some nice coreutils using busybox, pretty sure you can static link busybox nicely
<esselfe> yes, because I have glibc/binutils/gcc problems to comprehend the exact recompiling process and also want to expose better about static image solutions
<esselfe> an old baobab would be an example with an old GTK
<esselfe> I even plan on getting a better grasp of mid-details to start some docs about this interdependancy problematic that sometimes occurs around dynamic linking
<esselfe> ie autogen-5.18.12 refuse to configure-detect guile 2.2.2 since 1.8/2.0 versions are used and 2.2.2 haven't been implemented
<heat> the whole dependency issue with static linking is because of modules implemented as shared libs and using different versions of libx at runtime
<esselfe> well, I tried adding 2.2 in the configure, but it's about unresolved symbols, so...
<heat> dlopen() doesn't work on statically-linked programs, that's a big issue
<esselfe> but the kernel API from userspace is always standard right?
<heat> yes, the syscall API never changes
<esselfe> so ideally what I do when I upgrade glibc is reboot to an auxiliary/minimal OS having pretty much the same version than my main system. Then I chroot into it, update glibc, recompile isl/cloog/binutils/gmp/mpfr/mpc/gcc/m4/autoconf/automake/guile/make/autogen in order
<esselfe> then I do any other upgrades like usually using the package manager
* heat thinks that's hugely complicated and you need to stop building very very bleeding edge packages
<heat> or just get a better distro with a better package manager
<esselfe> I'm actually about writing some lxr-like documentation about software packages which details the versions of the deps causing problem, why
<esselfe> in fact, I'm very interested in fixing this unclear tendancy, but I want more details before being objective at it
<heat> the big problem is upgrading incompatible shared libraries, which then get undefined symbols
<esselfe> even worst, some have the same func sym, but segfault occurs ^^
<heat> also, the whole "we changed the API so nothing works correctly for you, fix your ****"
<heat> so then you end up needing to maintain different versions of the "same" package(see python2 and python3)
<heat> and then you just need to guess if /bin/python is symlinked to /bin/python2 or 3 - if it's linked to the wrong one, you're screwed
<esselfe> I was told using python and python3 was the preferred approach
<esselfe> there's python/python2 linked to python2.7 and python3 to python3.6m here
<esselfe> I think they should parse args: 'python -3'
<heat> the better solution is to just package up the shared libraries with you, so nothing breaks
<esselfe> dhcpcd -6 didn't go dhcpcd6, but ip6tables did, bizarre?
<heat> that allows you to not get rekt on library upgrades
https://en.wikipedia.org/wiki/Lunar_Linux
https://en.wikipedia.org/wiki/LXR_Cross_Referencer
https://en.wikipedia.org/wiki/BusyBox
https://en.wikipedia.org/wiki/AppImage (rem I'd prefer text only for a VT/tty environment)
https://en.wikipedia.org/wiki/GNU_Guix
https://en.wikipedia.org/wiki/Guix_System_Distribution
https://en.wikipedia.org/wiki/Linux-libre
