[OE-core] [PATCH 1/2] ldconfig: add method to extend ldconfig search dirs

Phil Blundell pb at pbcl.net
Wed Dec 9 21:41:35 UTC 2015


On Wed, 2015-12-09 at 12:40 -0800, akuster wrote:
> On 12/08/2015 02:34 PM, Phil Blundell wrote:
> > On Tue, 2015-12-08 at 13:05 -0800, akuster wrote:
> >> This is for ldconfig-native. The homebrew OE created. It has hard coded
> >> search patches. So OE only supports the standard /usr/* /lib* paths in
> >> the native part of the build.
> > 
> > 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 am most likely missing something really simple here. This is more
> about solving a problem than the fix I submitted. How would you solve
> this issue?

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.





More information about the Openembedded-core mailing list