OSDev.org https://forum.osdev.org/ |
|
static compilation for rescue that never fails after upgrade https://forum.osdev.org/viewtopic.php?f=15&t=32337 |
Page 1 of 1 |
Author: | sysenum [ Sun Aug 20, 2017 7:41 pm ] |
Post subject: | static compilation for rescue that never fails after upgrade |
Here's the IRC freenode conversation: Quote: <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 hum interesting... 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 |
Author: | Korona [ Mon Aug 21, 2017 12:41 pm ] |
Post subject: | Re: static compilation for rescue that never fails after upg |
If you want a statically linked binary on Linux just link against a libc that supports static linking, e.g. musl. Glibc needs dynamic linking to link against NSS libraries. |
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |