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

[Charles Wilson]

Avoid false positives, in which an actual library is
found in the default search path whose name matches
the 'magic' value used in the test, to exercise custom
loader. This false positive causes test failure.

* tests/dlloader-api.at: Check value of libtool variable
shlibpath_var, and define macro LT_MODULE_PATH_VAR.
(main.c): Ensure declaration of putenv.
(main.c:main): If LT_MODULE_PATH_VAR is defined, set the
variable it names to empty.

Signed-off-by: Charles Wilson <...>
---
On cygwin, the dlloader-api test fails. Reported here:
  http://lists.gnu.org/archive/html/bug-libtool/2010-06/msg00045.html
And followed up in this subthread:
  http://lists.gnu.org/archive/html/bug-libtool/2010-06/msg00077.html

There was additional discussion and analysis here:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00081.html
> Unfortunately, this doesn't magically assist solving my problem with
>    71. dlloader-api.at:23:  FAILED (dlloader-api.at:422)
> but that's not a reason to object to the patch.

and the ensuing thread, ending here:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00095.html
> However, the real issue isn't the exe magic, it's the fact that the test
> makes assumptions about what files ARE or ARE NOT in the
> LT_MODULE_PATH_VAR.  We *hope* that there is no "last" or "first" or
> "module" or "no_module" anywhere in there.

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
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
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
raised above...comments? discussion? Additional testing on esoteric
platforms? OK to push?

NOTE: From the autoconf manual:
  Posix prefers `setenv' to `putenv'; among other things, `putenv'
  is not required of all Posix implementations, but `setenv' is.
Unfortunately, MinGW and MSVC do not provide setenv but DO provide
_putenv.  Unless we want to extend the test using a custom
setenv implementation in terms of putenv for these two platforms,
(as done in the cwrapper code), and otherwise use setenv...this
seems simpler. But if we really CAN'T rely on putenv's presence...

Maybe uglification is the better way to go for this issue.

--
Chuck

 tests/dlloader-api.at |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/tests/dlloader-api.at b/tests/dlloader-api.at
index 37c8984..cd66b22 100644
--- a/tests/dlloader-api.at
+++ b/tests/dlloader-api.at
@@ -29,6 +29,18 @@ AT_DATA([main.c],
 #include <stdlib.h>
 #include <string.h>
 
+#if defined(__STRICT_ANSI__)
+# if defined(__MINGW32__)
+int _putenv (const char *);
+# elif defined(__CYGWIN__)
+int putenv (char *);
+# endif
+#endif
+
+#if defined(__MINGW32__) || defined(_MSC_VER)
+# define putenv  _putenv
+#endif
+
 static int
 first_init (lt_user_data data)
 {
@@ -175,6 +187,14 @@ main (int argc, char* argv[])
   const char *last_ctx = "last_ctx";
   const lt_dlvtable *finder;
 
+#ifdef LT_MODULE_PATH_VAR
+  static char path_var[] = LT_MODULE_PATH_VAR "=";
+  if (putenv (path_var) != 0)
+    {
+      printf ("putenv(\"%s\") failed\n");
+    }
+#endif
+
   LTDL_SET_PRELOADED_SYMBOLS ();
 
   if (lt_dlinit ())
@@ -402,6 +422,10 @@ AT_CHECK([case $LIBLTDL in #(
 esac], [], [ignore])
 
 CPPFLAGS="$LTDLINCL $CPPFLAGS"
+eval `$LIBTOOL --config | grep 'shlibpath_var='`
+if test -n "$shlibpath_var"; then
+  CPPFLAGS="$CPPFLAGS -DLT_MODULE_PATH_VAR=\"$shlibpath_var\""
+fi
 
 AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c module.c],
         [], [ignore], [ignore])
-- 
1.7.0.4