libgrapheme

Freestanding C library for unicode string handling
git clone https://git.sinitax.com/suckless/libgrapheme
Log | Files | Refs | README | LICENSE | sfeed.txt

commit fd8f4f4e496ba83bba253b52787ccde39384f99a
parent c213f3ca7b8ca8974f7eb22752e247e36f633f16
Author: Laslo Hunhold <dev@frign.de>
Date:   Wed, 22 Dec 2021 12:56:33 +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@frign.de>

Diffstat:
MMakefile | 2++
1 file changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile @@ -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 @@ -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