The Place to Start for Operating System Developers
It is currently Sat Jan 20, 2018 7:18 am

All times are UTC - 6 hours

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: static compilation for rescue that never fails after upgrade
PostPosted: Sun Aug 20, 2017 7:41 pm 

Joined: Sat Aug 19, 2017 9:53 pm
Posts: 2
Here's the IRC freenode conversation:

<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 :P
<esselfe> I think they should parse args: 'python -3' :P
<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/AppImage (rem I'd prefer text only for a VT/tty environment)

Last edited by sysenum on Wed Aug 23, 2017 6:48 am, edited 1 time in total.

 Post subject: Re: static compilation for rescue that never fails after upg
PostPosted: Mon Aug 21, 2017 12:41 pm 

Joined: Thu May 17, 2007 1:27 pm
Posts: 425
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.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 6 hours

Who is online

Users browsing this forum: Yahoo [Bot] and 5 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group