Re: [PATCH] Set library search path empty in dlloader-api test.

[Charles Wilson]

On 6/20/2010 2:31 AM, Charles Wilson wrote:
> This patch takes the approach that we should not make any assumptions
> about files in $LD_LIBRARY_PATH or $PATH -- especially when the
> name of the "library" we're attempting to lt_dlopen is not uglified:
> "last" is a quite command /usr/bin/ command.  On cygwin, the library
                    ^^^^^^^
                    common

> search path for libs to dlopen includes $PATH; since /usr/bin is in
> $PATH, /usr/bin/last is found, and we attempt to open it. (The cygwin
> auto-recognize-.exe behavior discussed in some of the links above is
> a red herring; yes, it makes a difference here, but the problem is
> actually more general).
> 
> Anyway, attempting to dlopen this object /usr/bin/last could either
> succeed or fail (it fails on cygwin) -- but in either case, we would
> NOT in fact be testing the custom loader at the end of the loader
> chain in this test (also named "last").
> 
> When we fail (as on cygwin), NO further attempt is made -- either to
> search in additional directories in the library search path, or to
> attempt to dlopen the bare name "last" without prefixing any
> components of the library search path.
> 
> We just report failure to the (in-library) caller, and go to the
> next registered loader. Since, in this test, we're talking about the
> "last" loader, this is our last chance, and we report failure to
> the client application.  (However, the same probably can be observed
                                              ^^^^^^^^
                                              behavior

> with the "first" loader; but the details are slightly different).
> 
> Usually this is the correct decision; the mistake, in this case, was
> in allowing elements NOT under our control (e.g. contents of system
> directories) to violate the constraints of the test.  To enforce
> these constraints -- no possible loadable item shall match the
> (base)name of the item we use to test the custom loader -- this patch
> sets the library search path to empty.
> 
> It is not clear to me whether this would break some platforms, if:
>   we need to dlopen a module, say "foo.so"
>   foo.so depends on some installed shared library, somewher
>     in the (system) library search path. Say, /lib/libc.so
>   if we unset the library search path, will the platform
>     still be able to dlopen foo.so? Even though one of foo.so's
>     dependencies, libc.so, can no longer be found via searching
>     the (now empty) library search path?
> 
> An alternate "solution" would be to uglify the name: rather than
> trying to load a "library" named "last", instead load one named
> "libtool_test_suite_custom_dlloader_last".  There PROBABLY would
> never be an ACTUAL loadable object with that name in $PATH or
> $LD_LIBRARY_PATH...
> 
> Tested on cygwin, mingw, linux, and works. But, given the issues
                                     ^
                                     it

> raised above...comments? discussion? Additional testing on esoteric
> platforms? OK to push?