Add ldconfig alt lib search paths

I have a customer who wanted to define alt ldconfig search paths on a per recipe basis and adding hardcoded search paths in ldconfig-native does not scale well.

Here is a prototype scheme to allow extending the search path for ldconfig-native without hardcoding.

Alt search paths can be defined in a recipe or via local.conf.

This works in this form but I suspect there are cleaner or better schemes.

enjoy.

Armin Kuster (2):
ldconfig: add method to extend ldconfig search dirs
ldsoconf: allow extension via local.conf

 meta/classes/image-ldconfig.bbclass | 32 ++++++++++++++++++++++++++++++++
 meta/classes/ldconfig.bbclass       | 27 +++++++++++++++++++++++++++
 meta/conf/bitbake.conf              |  8 ++++++++
 3 files changed, 67 insertions(+)
 create mode 100644 meta/classes/image-ldconfig.bbclass
 create mode 100644 meta/classes/ldconfig.bbclass

2.3.5

From: Armin Kuster <[email protected]>

this provides a method to extend the search path ldconfig-native uses when creating ls.so.cache.

To enable in recipe:

add:
inherit ldconfig

LDSOCONF = "/opt/lib"

this will create a ld.so.conf file in work-shared/ldconfig/${PN}/

to create an image with these new search paths included, add to local.conf:

INHERIT += "image-ldconfig"

this will take all the ${PN}/ld.so.conf files and create a single ld.so.conf that will be used by ldconfig-native when building an image.

---
 meta/classes/image-ldconfig.bbclass | 26 ++++++++++++++++++++++++++
 meta/classes/ldconfig.bbclass       | 27 +++++++++++++++++++++++++++
 meta/conf/bitbake.conf              |  5 +++++
 3 files changed, 58 insertions(+)
 create mode 100644 meta/classes/image-ldconfig.bbclass
 create mode 100644 meta/classes/ldconfig.bbclass

new file mode 100644
index 0000000..e9946da
@@ -0,0 +1,26 @@
+#
+# To enable, use INHERIT in local.conf:
+#
+#       INHERIT += "image-ldconfig"
+
+do_rootfs[depends] += "ldconfig-native:do_populate_sysroot"
+
+IMAGE_PREPROCESS_COMMAND += "ld_so_conf; "
+
+ld_so_conf() {
+
+    rm -f ${STAGING_DIR_NATIVE}${sysconfdir_native}/ld.so.conf
+
+    # save lib dirs as defined in recipes
+    for file in `find ${STAGING_LDSO_CONF_DIR}/*/* -name "ld.so.conf"`;
+    do
+        cat ${file} >> ${STAGING_LDSO_CONF_DIR}/ld.so.conf
+    done
+
+    # remove dups and sort
+    cat ${STAGING_LDSO_CONF_DIR}/ld.so.conf | sort -u > ${IMAGE_ROOTFS}/etc/ld.so.conf
+
+    # this seems to work if at rootfs location.
+    cd ${IMAGE_ROOTFS}
+    ${STAGING_DIR_NATIVE}${bindir_native}/ldconfig -r . -c new -f etc/ld.so.conf 
+}

new file mode 100644
index 0000000..558122f
@@ -0,0 +1,27 @@
+# Allows adding libs or alt lib locations to be included
+# during ld.so.cache creation.
+#
+#
+
+do_package[postfuncs] += "save_ld_so_conf "
+do_clean[cleandirs] += "${STAGING_LDSO_CONF_DIR}/${PN} "
+
+python save_ld_so_conf() {
+    import os
+
+    if (d.getVar('USE_LDCONFIG', True) or "1") == "1":
+        ldsodir = d.getVar('STAGING_LDSO_CONF_DIR', True)
+        if not os.path.isdir(ldsodir):
+            os.mkdir(ldsodir)
+    
+        staging_ld = os.path.join(ldsodir, d.expand("${PN}"))
+        if not os.path.isdir(staging_ld):
+            os.mkdir(staging_ld)
+
+        ldsofile = os.path.join(staging_ld, 'ld.so.conf')
+
+        ldconf = d.getVar('LDSOCONF', True).split()
+        with open(ldsofile, 'w') as lsdo:
+            for ldso_entry in ldconf:
+                lsdo.write(ldso_entry+"\n")
+}

index 06971da..f0471f4 100644
@@ -811,3 +811,8 @@ BB_SIGNATURE_EXCLUDE_FLAGS ?= "doc deps depends \
 
 MLPREFIX ??= ""
 MULTILIB_VARIANTS ??= ""
+
+# 
+# ldconfig stuff
+#
+STAGING_LDSO_CONF_DIR = "${TMPDIR}/work-shared/ldconfig"

2.3.5

ping

The problem that you're solving here seems like fundamentally a distro one. I remain slightly sceptical that the whole concept of ldconfig makes a lot of sense for the majority of oe-core users and, for those for whom it does, I don't entirely understand why it doesn't suffice to have the packages with unusual requirements install an appropriate file in /etc/ld.so.conf.d/ and the distro arrange for /etc/ld.so.conf to include all of those.

So, can you provide a bit more explanation as to why this patch is a good thing?

p.

In that case, given that you're talking about image construction, isn't the right thing to make ldconfig-native respect whatever search paths it's given by /etc/ld.so.conf in the image filesystem?

I assume the point you're making here is that this ends up reading the host's /etc/ld.so.conf, not the one in the image. Is that right?

p.

Well, I suspect I'm not understanding the whole problem. But here's my view.

Firstly, it's not entirely obvious to me that individual recipes have any business fiddling with the shared library search paths in the first place. If they want to install their own libraries somewhere odd, that's what rpath is for. But of course, if the distro wants to add something to the library search path then it is entitled to do so.

Secondly, ldconfig is only a performance optimisation (or pessimisation, depending on your point of view) and the system ought to work correctly without it. Your proposed patch seems like it will not work if ldconfig is not in use, because the ld.so.conf generation is conditioned on USE_LDCONFIG.

Thirdly, on systems which do have ldconfig the user might re-run it on the target at any time. This means that you can't rely on the output from ldconfig-native remaining intact forever: instead, the directories with libraries in them need to be mentioned in the
image's /etc/ld.so.conf, either directly or indirectly. The most scalable way to do that is for the distro to put a line in that file that reads "include /etc/ld.so.conf.d/*.conf" or some such, and then individual recipes can just drop their own files into /etc/ld.so.conf.d. But if individual distros want to just ship a static ld.so.conf file then that ought to be fine as well.

Fourthly, if we do accept that random packages can modify the search path, whatever mechanism is used to deal with this needs also to work for runtime package management. Anything that relies on creating ld.so.conf statically during image creation may not going to be sufficient in the general case, otherwise packages that put libraries in odd places will be unusable if installed afterwards.

Fifthly, given the above, there oughtn't to be any need for a separate mechanism to tell ldconfig-native what paths to search: it should just read the same /etc/ld.so.conf in the image (and things included from it) as ldconfig will read at run time. If it isn't doing that then I would argue this is just a bug and ought to be fixed there.

Sixthly, whatever we do ought to be deterministic. Your proposed patch looks like it will hoover up everything from STAGING_LDSO_CONF_DIR and put it in the image, irrespective of whether the package that created any particular file in STAGING_LDSO_CONF_DIR is actually being installed in the current image or not. That is, if I do:

$ rm -rf tmp-glibc
$ bitbake core-image
$ bitbake opie-image
$ bitbake core-image

then I would expect the two core-image outputs to be the same, even though some opie packages might have inveigled themselves into STAGING_LDSO_CONF_DIR in the meantime.

So in summary I think we need to either:

a) accept that arbitrary recipes can modify the ld.so search path and figure out a way to make that work correctly in all situations; or

b) decide that the ld.so search path is basically a piece of static image configuration, in which case all we need is a variable that the distro or image can set and that image.bbclass will write into /etc/ld.so.conf. In this situation there is no need for a new class or a folder inside the staging area.

Maybe it'd help if you could provide a couple of concrete examples of the real problem that you're trying to solve.

p.

From: Armin Kuster <[email protected]>

this allows extending ldconfig search path from local.conf

---
 meta/classes/image-ldconfig.bbclass | 6 ++++++
 meta/conf/bitbake.conf              | 3 +++
 2 files changed, 9 insertions(+)

index e9946da..ce10673 100644
@@ -11,6 +11,12 @@ ld_so_conf() {
 
     rm -f ${STAGING_DIR_NATIVE}${sysconfdir_native}/ld.so.conf
 
+    # dump addition lib possible defined in local.conf
+    for file in ${LDSOCONF};
+    do
+        echo ${file} >> ${STAGING_LDSO_CONF_DIR}/ld.so.conf
+    done
+
     # save lib dirs as defined in recipes
     for file in `find ${STAGING_LDSO_CONF_DIR}/*/* -name "ld.so.conf"`;
     do

index f0471f4..1f78c49 100644
@@ -815,4 +815,7 @@ MULTILIB_VARIANTS ??= ""
 # 
 # ldconfig stuff
 #
+EXTRA_LDSOCONF ??= ""
+LDSOCONF = "/lib /lib64 /usr/lib /usr/lib64"
+LSSOCONF += "${EXTRA_LDSOCONF}"
 STAGING_LDSO_CONF_DIR = "${TMPDIR}/work-shared/ldconfig"

2.3.5

A sane default make more sense.

These libs are currently hardcoded in ldconfig-native. #define LIBDIR "/usr/lib"
#define LIBDIR32 "/usr/lib32"
#define LIBDIR64 "/usr/lib64"
#define SLIBDIR "/lib"
#define SLIBDIR32 "/lib32"
#define SLIBDIR64 "/lib64"

looks like I missed lib32 versions.

not checked today either. Maybe we can use this scheme to dynamically append ldconfig search patches for the mips example?

ldconfig just gives a warning if the lib dirs don't not exist.

sounds like this needs to be extended to handle multi lib better or in a saner method.

thanks,
- armin