[hackers] [libgrapheme] Call ldconfig after install and uninstall || Laslo Hunhold

From: <git_AT_suckless.org>
Date: Wed, 22 Dec 2021 13:05:44 +0100 (CET)

commit fd8f4f4e496ba83bba253b52787ccde39384f99a
Author: Laslo Hunhold <dev_AT_frign.de>
AuthorDate: Wed Dec 22 12:56:33 2021 +0100
Commit: Laslo Hunhold <dev_AT_frign.de>
CommitDate: Wed Dec 22 12:56:33 2021 +0100

    Call ldconfig after install and uninstall
    
    Linux, the BSDs and many other UN*X operating systems have a cache
    in /etc/ld.so.cache which contains information for the dynamic linker
    on how to resolve a given dynamic library reference.
    
    When after installing libgrapheme we compile a dynamically linked binary
    
       $ cc -o test test.c -lgrapheme
    
    and inspect it with ldd (be careful with that and only run it on trusted
    binaries!) we get:
    
       $ ldd test
               linux-vdso.so.1 (0x00007ffd121b5000)
               libgrapheme.so => not found
               libc.so.6 => /lib64/libc.so.6 (0x00007efcb726e000)
               /lib64/ld-linux-x86-64.so.2 (0x00007efcb745b000)
    
    The library refers to libgrapheme.so, but the linker cannot find it. How
    come? We have properly installed it in /usr/local/lib and it is present
    there!
    
    The thing is that the system has to be told to update its cache. Some
    systems also rebuild the cache on each reboot, but you can do it
    manually using ldconfig(1), which needs to be run as root.
    
    When doing that and checking the binary again, we get as expected:
    
       $ ldd test
               linux-vdso.so.1 (0x00007ffc7060b000)
               libgrapheme.so => /usr/local/lib/libgrapheme.so (0x00007f591eac4000)
               libc.so.6 => /lib64/libc.so.6 (0x00007f591e909000)
               /lib64/ld-linux-x86-64.so.2 (0x00007f591eafe000)
    
    and the binary runs fine.
    
    However, there may be circumstances where ldconfig doesn't need to be
    called or won't work. There might be systems doing the caching in a
    better way (e.g. regenerating the cache when encountering a binary with
    missing dynamic libraries, which would make sense) or the user might
    install libgrapheme in their own local directory hierarchy without
    even running make install as root.
    Thus we simply ignore the return value of ldconfig. We have tried giving
    the system a hint that it should regenerate caches, but if it fails for
    one reason or another, we couldn't care less.
    
    Signed-off-by: Laslo Hunhold <dev_AT_frign.de>

diff --git a/Makefile b/Makefile
index cdda874..aca57a1 100644
--- a/Makefile
+++ b/Makefile
_AT_@ -97,6 +97,7 @@ install: all
         cp -f libgrapheme.a "$(DESTDIR)$(LIBPREFIX)"
         cp -f libgrapheme.so "$(DESTDIR)$(LIBPREFIX)"
         cp -f grapheme.h "$(DESTDIR)$(INCPREFIX)"
+ ldconfig || true
 
 uninstall:
         for m in $(MAN3); do rm -f "$(DESTDIR)$(MANPREFIX)/man3/`basename $$m`"; done
_AT_@ -104,6 +105,7 @@ uninstall:
         rm -f "$(DESTDIR)$(LIBPREFIX)/libgrapheme.a"
         rm -f "$(DESTDIR)$(LIBPREFIX)/libgrapheme.so"
         rm -f "$(DESTDIR)$(INCPREFIX)/grapheme.h"
+ ldconfig || true
 
 clean:
         rm -f $(GEN:=.h) $(GEN:=.o) gen/util.o $(GEN) $(SRC:=.o) src/util.o $(TEST:=.o) test/util.o $(TEST) libgrapheme.a libgrapheme.so
Received on Wed Dec 22 2021 - 13:05:44 CET