Re: static linking working w/gnu? (was Re: [ANNOUNCE] util-linux v2.33-rc1)

[L A Walsh <lkml@tlinx.org>]

On 10/8/2018 2:09 AM, Karel Zak wrote:
> On Mon, Oct 08, 2018 at 12:30:50AM -0700, L A Walsh wrote:
>   
>> 	Did you get warnings similar to the above?  The claim
>> is that you should be getting similar errors, but I got the impression
>> that you did not.
>>     
>
> I get the warning, but result is still static binary. Don't ask me why
> ;-)
>
> $ file ./mount.static 
> ./mount.static: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=b66bae970bf72346cbf6d844e0e48d5dbfd07cc2, with debug_info, not stripped
>
> The problem is the way how glibc uses stuff around NSS. In this case
> glibc needs runtime modules, for more details see:\
>   
---
    Well, it could easily use a run-time dynamic load and if the libs were
not present indicate that some feature is not available.
>   https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F
>
> on Fedora, the mount.static is static, but I guess glibc internally
> uses some ldopen() when need NSS or iconv stuff.
>   
----
    Maybe, I got the impression that they only knew how to do
load-time linkage.  One might alter resolve.conf and see if its
possible for force mount to look for something and see its behavior,
however, what I've run into are the newlibs in util-linux (libblk...,
libsmartcols...etc) being put on /usr/lib64 which is on a separate 
partition.
So with 'mount' dead, you can't mount the new partition.

    Answer is to either statically link (best, if possible), or
put the libs on the same partition as the binaries.

> I think you do not want to try resolve this issues in the utils.
---
    It really depends on resolving issues used in early HW bring-up.
> It's all about libc design. If glibc does not well for you, then 
> you need something else. For example uclibc, or glibc without NSS,
> etc.
>   
----
    musl seemed to work well when I tried it, but would rather not do
that if there is an easier way.

> Now you know why we have projects like dracut for initramfs.
----
    Because people have moved the system dependent stuff off the root --
which goes against the usrmerge docs which say to only put OS/system
_independent_ stuff on /usr. 
If that had been done, then everything I needed to
run mount and bring up the generic system would have already been on root.


>  It's
> better to use standard libs and utils than try to build parallel
> universe to boot or for rescue disks.
>   
---
    Not trying to build parallel universe -- that universe already
exists.  Just trying to make it more robust in face of randomness.

    Relying on systemd's idea of an emergency  or rescue disk doesn't
work because it reboots after you have made temporary corrections.  It
needs to come up so a longer term solution can be applied, systemd
wouldn't come up because a kernel mod wasn't loaded.  Normally, I'd
just load the module by hand, but systemd's emergency disk won't
continue after you make a correction -- instead, it reboots. 

    One can find faults with any system.  Someday, systemd may be
as reliable as a shell -- but it isn't there yet.


>