On Thu, Jul 24, 2008 at 05:41:04PM -0700, Nishanth Aravamudan wrote: > On 24.07.2008 [21:48:19 +0100], Andy Whitcroft wrote: > > On Thu, Jul 24, 2008 at 01:49:24PM -0500, Adam Litke wrote: > > > On Thu, 2008-07-24 at 17:44 +0100, Andy Whitcroft wrote: > > > > Add support for requesting a specific library set for preload. This > > > > adds > > > > the --library option which takes an optional argument. Without an > > > > argument > > > > it requests use of the specific libraries installed with the version > > > > of hugectl in use. An argument is treated as a prefix to the library > > > > directories and the approprate 32/64 bit library directories are added. > > > > > > Hmm, there is a use case that this patch doesn't cover (and it was the > > > first thing I thought of when I saw the patch title). Say I have a > > > pre-built library in /home/aglitke (or some such path without lib/lib64 > > > structure) that I want to use. The patch (as it exists now) would not > > > let me point hugectl at this library. Am I the only one who thinks this > > > might be useful? I suppose one option is to make users wanting to do > > > this simply use LD_LIBRARY_PATH directly. > > > > I can probabally sort out a way to specify that too. Will consider it > > further in the morning. > > > > Checking directly for the library in the passed directory name then use > > it directly would do the trick. > > Now, I may have just missed things in the previous editions of this > patch and the discussions thereafter, but I feel like this particular > patch may be more complicated than it needs to be. For hugectl, I > envision one of two use cases: > > a) Use the system's library resolution (which is either going to have > been configured for ld.so via /etc/ld.so.conf or whatever (something > distro-specific) or set via LD_LIBRARY_PATH by the administrator/user) > to find the library, which should be the default. > > b) Allow the user to specify the path to the library they would like to > use. > > That is, I dont't think we need any extra options beyond > > hugectl --library-path= > > Is there a reason for anything else? I can't think of one from my > experience with users/customers. I don't think hugectl should be aware > of what library it was installed with. It should just use the normal > resolution methods (that is, the default library to load is not > hard-coded). That should simplify the patch, as well. > > FWIW, the comment indicates that --library is the only option being > added, but I believe there were two added in the patch.
The default action is to ensure we use the library which matches hugectl, that is there so that if you have 2.0 and 2.1 installed you get the versions which match the version of hugectl you have selected, much as you get the version of libgcc.a that matches the version of gcc you are running. If that is not required the yes the patch would simplify. -apw ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
