ldconfig Implementation

[dslm4515]

Per musl-libc.org:

Where is ldconfig?
There isn’t one. You can specify the library search path by creating or editing the file /etc/ld-musl-$ARCH.path, where $ARCH is the string identifying your architecture (look at what /lib/ld-musl-*.so.1 uses if uncertain). Paths can be separated by newlines or colons. The environment variables LD_PRELOAD and LD_LIBRARY_PATH are also supported for one-off cases.

For debian/ubuntu systems there is ld-musl-config:

ld-musl-config reads in all config files found under /etc/ld-musl-$ARCH.d, and creates a concatenated linker path config file in /etc/ld-musl-$ARCH.path This file will be used by the musl dynamic run-time linker.
Paths can either be separated with a newlines or with a ':' character.
ld-musl-config can be called at any time to regenerate the linker path config file. The previous config will be overwritten.
/etc/ld-musl-$ARCH.path = Generated by ld-musl-config and contains an ordered list of library path's.
/etc/ld-musl-$ARCH.d/* = Path config files to be read in by ld-musl-config.

But for glibc, ldconfig accepts arguments:

ldconfig [-nNvVX] [-C cache] [-f conf] [-r root] directory ...
ldconfig -l [-v] library ...
ldconfig -p

And describes ldconfig as:

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories, /lib and /usr/lib.

The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated. ldconfig should normally be run by the superuser as it may require write permission on some root owned directories and files.

Chimera Linux has ldconfig as a link to true so that when used in scripts, calls to for ldconfig always execute successfully without doing anything.

I wonder what are the pro's and con's for these two "implementations" of ldconfig

• ldconfig as a link to true
• ldconfig as a script to generate a ld-musl-$ARCH.path from a directory of config files

[dslm4515]

If ldconfig is a script to build ld-musl-$ARCH.path from a directory of config files ... then this comes in handy for when packages are removed from a system.

Whenever a library is uninstalled, the Path config files can be removed too and then the ld-musl-$ARCH.path can be rebuilt without using "uninstall" scripts to update it (remove the deleted library paths).

[firasuke]

So did you find a suitable ldconfig implementation for use with musl libc?

[dslm4515]

I decided to use Debian's ld-musl-config. It makes it easier to add and remove paths when installing/uninstalling packages.

[firasuke]

I see, but is this functionality even needed with musl in the first place?

[dslm4515]

It depends. For example, I like to install Qt5 in /opt/qt5.

Either i build the Qt5 packages ...

o With LDFLAGS=-Wl,-rpath=/opt/qt5/lib -- then no need to add paths to /etc/ld-musl-${MCA}.path

OR

o Without LDFLAGS=-Wl,-rpath=/opt/qt5/lib -- I would need to add /opt/qt5 to /etc/ld-musl-${MCA}.path

But you're right because during my first few years of using a Musl-based system as my daily driver, I rarely needed to to use ldconfig or add paths to /etc/ld-musl-${MCA}.path.

Now that I think of it more .... ln -sv true /bin/ldconfig is really just a compatibility link to avoid breakage in scripts and building certain packages.

So I could just make it an optional script to install.