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. Thanks, Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center ------------------------------------------------------------------------- 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
