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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
