This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] do not disregard LD_LIBRARY_PATH for native c++ tests


> There's a v3track wrapper to help keep an eye on what these variables
> are holding.  It's used only a few times in the init routines.  It could
> be renamed and reused.  The only downside is that at verbosity levels
> 2 and higher, a /lot/ of chatter from the rest of the framework appears.
> (I prefixed the messages with '++' or '==' or something to help our messages
> stand out.)  We can be more complex/clever with verbosity variables if we
> feel the need, but I would rather look into Tcl's facilities for actually
> tracing variables and printing notices when they are modified.

I also see in libjava.exp:

proc ${tool}_set_ld_library_path { name element op } {
  setenv LD_LIBRARYN32_PATH [getenv LD_LIBRARY_PATH]
  setenv LD_LIBRARY64_PATH [getenv LD_LIBRARY_PATH]
  setenv SHLIB_PATH [getenv LD_LIBRARY_PATH]
  setenv DYLD_LIBRARY_PATH [getenv LD_LIBRARY_PATH]
  setenv LD_LIBRARY_PATH_32 [getenv LD_LIBRARY_PATH]
  setenv LD_LIBRARY_PATH_64 [getenv LD_LIBRARY_PATH]
}

trace variable env(LD_LIBRARY_PATH) w ${tool}_set_ld_library_path

This seems to use a facility to watch LD_LIBRARY_PATH.  Possibly this
approach could be used everywhere.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]