Mark, On 14/07/11 03:27, Mark Hatle wrote: > On 7/13/11 12:22 PM, Howard D. Gray wrote: >> Hi, >> >> IMHO it would be useful if packages could install their own *.conf files >> in /etc/ld.so.conf.d/ ...
> > I agree this is a good idea, however... > > If the apps you are creating require ld.so.conf, and thus ldconfig in order to > execute.. then most likely the app in question has a bug.. (I say most > likely, > because that is not always true.) > > For the systems I work with, my rule of thumb is that everything that goes > into > a system directory should never need ldconfig to run... If it does, it means > there is a broken soname somewhere in the system. > > For items that are outside of the standard set of directories, they should > have > rpaths embedded (based on the target filesystem) that tell the components how > and where to find their non-standard located components. > (chrpath can do this in many cases..) OK. For our applications I think we should be able to use rpath when building as you suggest or possibly tweak the rpath tag with chrpath during installation. I have only very limited control over the build process for the libraries used by this app - in particular the directory hierarchy - which is why I preferred to install them somewhere non-standard. > Sometimes when using third party binaries that is not possible of course.. > However, creating a simple shell wrapper that adds the necessary paths to > LD_LIBRARY_PATH is a good solution. This is a solution we have used before but it caused confusion for normal Linux users with a PC. However, on an embedded board it could be the simplest option. > But, if all else fails, ld.so.conf should work. > > IMHO all of the alternatives are better approaches because they ensure the > apps > and system components work as intended, and don't rely on the crutch of the > dynamic loader cache to be able to find the intended items. Speed wise, if > the > items are in the standard directories there is no performance penalty (thats > I've been able to determine) to -not- have an ld.so.cache on the system.. for > items outside of the standard directories, the penalty is so minor -- and only > occurs on app startup that it still doesn't make sense to me to have an > ld.so.cache... (it simply takes a lot of disk space, and requires an ldconfig > operation to occur.) > > Long story short, I don't mind the suggestion.. but I will look for > alternatives > to someone putting in a .conf file over allowing the .conf file any day. Just adding the "include" line to ld.so.conf only opens up the possibility for other apps to maintain their own *.conf files without having to worry about other paths in ld.so.conf. It doesn't mean that *.conf files *have* to be used or that ld.so.cache will be required on a system without such *.conf files. Of course, it might be considered to be encouraging "bad practices". In our case I should be able to use one of the other ways you suggest and I'll try to do it like that first. Thanks a lot for taking the time to explain. -- Howard MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel