Make ld.so.conf include files from /etc/ld.so.conf.d

[Marcel van den Boer]

Currently, LFS lists directories containing libraries directly in /etc/ld.so.conf. However, there are advantages in changing the contents of ld.so.conf to "include /etc/ld.so.conf.d/*.conf", and then place it's current contents in /etc/ld.so.conf.d/glibc.conf.

Personally, I have been using this method for years (and so have the big distributions) and found it to be the more elegant solution.

Advantages become apparent when you use BLFS and/or often (un)install software in /opt:

Each new package requiring additional search paths can store them in their own file, meaning ld.so.conf does not have to be modified any more; No chance of accidentally removing existing paths or cluttering up the file. When uninstalling a package, in stead of modifying ld.so.conf again, you can simply delete the configuration file belonging to that package.

Concerns:

Both LFS and BLFS should be modified. Only modifying LFS defeats the purpose of the change.

Should BLFS be modified accordingly, people who blindly copy-paste commands and have an older version of LFS installed (and therefore do not have ld.so.conf.d) will experience problems. To limit this as much as possible, BLFS should (at least temporarily) warn "Make sure you have set up /etc/ld.so.conf.d as explained in LFS-6.9 and if not, make this change now.".

[Bryan Kadzban]

BLFS doesn't even (by default) recommend putting packages into /opt. See the last sentence at ​http://www.linuxfromscratch.org/blfs/view/svn/introduction/position.html for instance. From what I can see with a cursory glance at BLFS, the only package groups that use /opt are Qt, KDE, and GNOME, and most of those are clearly marked optional. (/usr is another perfectly valid option.)

I think this is a lot of complication for not much clear benefit.

Maybe it'd be worth noting this possibility somewhere near that /introduction/position.html file (especially since the change can be made at any time, with a bit of care), but I'm not sure it makes sense to make this the primary method of configuration.

[bdubbs@…]

The way BLFS handles finding libraries in /opt is to use symlinks and add the symlink to ld.so.conf. That's not to say that adding /etc/ld.so.conf.d/ would be inappropriate.

If someone wants to suggest some text to describe the alternate method, it wouldn't hurt add that to section 6.9.3. That said, the reason for most of the .d/ type directories is for distros to drop in binary packages without editing files. That type of reasoning is not a major consideration for a system like LFS.

I personally like putting important packages in versioned directories in /opt because it makes it easy to try things out and then revert if necessary. This is fairly important for things like X, complex windowing environments (KDE, Gnome), and large support libraries (Qt).

[DJ Lucas]

Replying to bdubbs@…:

the reason for most of the .d/ type directories is for distros to drop in binary packages without editing files. That type of reasoning is not a major consideration for a system like LFS.

I would disagree with the last statement, I've always disliked the following syntax used in BLFS:

cat >> /etc/ld.so.conf << "EOF"
# Begin addition for foo
/opt/foo/lib
# End addition for foo
EOF

All my opinion of course, but the result of the above is a little sloppy looking, and *.d directories are a major improvement in aesthetics and usability, with only a very minor bump in complexity (and even that is debatable as modular files logically organize into smaller to digest bits for the user to understand).

[bdubbs@…]

Perhaps the comments are a little much, but how long is your ld.so.conf file anyway? Mine is 15 lines, counting 2 comments and 3 blank lines. I'd much rather see all the lines together than a bunch of one line files.

We each do things a little differently. That's the purpose of LFS. Explaining an alternative is reasonable.

[Marcel van den Boer]

Suggested change

[Marcel van den Boer]

I usually automate the build of my system, which used to result in a file looking like this:

# Begin /etc/ld.so.conf

/usr/local/lib
/opt/lib

# End /etc/ld.so.conf
# Begin qt addition to /etc/ld.so.conf

/opt/qt/lib

# End qt addition
# Begin kde addition to /etc/ld.so.conf

/opt/kde/lib

# End kde addition
# Begin gnome addition to /etc/ld.so.conf

/opt/gnome/lib

# End gnome addition

I agree that if people do not like the way this looks, they can easily remove the clutter themselves. But this is the result when following BLFS to the letter.

Changing the BLFS instructions should fix this:

<start>
Create a new dynamic loader configuration file for <package>, or manually add the directories to /etc/ld.so.conf:

cat > /etc/ld.so.conf.d/<package>.conf << "EOF"
# Begin <package> addition to the dynamic loader search paths

/opt/<package>-<version>/lib

# End <package> addition
EOF

<end>

In BLFS, the following packages suggest adding entries to ld.so.conf: Xorg, Gnome, Qt3, Qt4 and KDE. Furthermore, grep tells me that gcc3, cdparanoia, sdl and the introduction mention ld.so.conf in some way.

[bdubbs@…]

Added optional instructions that explains how to add /etc/ld.so.conf.d as an include directory for the loader.

Fixed in revision 9496.

[(none)]

Milestone 6.9 deleted