Re: Auto append of .dll for a gSystem->Load

From: Valery Fine (fine@mail.cern.ch)
Date: Wed Oct 15 1997 - 22:15:38 MEST


On 14 Oct 97 at 22:47, Gordon Watts (Brown Universit wrote:

> Hi,
>   I'm observing some funny behavior when I load a dynamic library,
>   so I
> started looking at the source code. Thus, this email:
> 
> 1) In WINNT_WinNTSystem.cxx, in the routine DynamicPathName  there
> is the following code which is used to auto append ".dll" onto a
> string (a great idea, from the portability point of view):
> 
>    if (!strchr(lib, '.')) {
>       name = Form("%s.dll", lib);
>       name = gSystem->Which(GetDynamicPath(), name,
>       kReadPermission);
>    }
>    else {
>        int len = strlen(lib);
>        if (len > 4 && !(strnicmp(lib+len-4, ".dll",4)))
>        {
>            name = gSystem->Which(GetDynamicPath(), lib,
>            kReadPermission);
>        }
>        else {
>            ::Error("TWinNTSystem::DynamicPathName",
>                "DLL library must have extension: .dll", lib);
>            name = 0;
>        }
>    }
> 
> I think this doesn't take into account relative paths. A filename
> like "../eejj_ntuple_objects/eejj_ntuple_objects" will fail that
> first if statement, where it really shouldn't... (I need to use
> relative paths because I'm always moving between various machines).
> 
> 2) Second, I've observing a very strange behavior. I have a .dll
> that is several directories away from my current location in root. I
> would like to do something that looks like this:
> "gSystem->Load("../eejj_ntuple_objects/Debug/eejj_ntuple_objects.dll
> ");" but that fails. However, if I copy the eejj_ntuple_objects.dll
> into my local directory, or invoke root while sitting in the
> directory where eejj_ntuple_objects.dll resides it works. Further,
> another .dll does load:
> gSystem->Load("../../mass_fitter/Debug/mass_fitter.dll")" The sucess
> or failure is indicated by the return value of the gSystem->Load
> routine. Have others seen something like this? I can try to put
> together a test case, but I don't really understand this error
> enough...
> 
  The TSystem::Load method looks like this 

   if (IsAbsoluteFileName(module))
      i = G__loadfile((char *)module);
   else if (path = DynamicPathName(module)) {
      char *s = ConcatFileName(path, module);
      i = G__loadfile(s);

   I suppose the reason for this trouble is a different 
implementation of TSystem::Which() method.

  As you mentioned under Windows the "_searchenv" MSVC subroutine was 
used. It seems this subroutine accepts only the "pure" filenames to 
search (with no path part), at least I found no comment on this and 
one needs to check this with a simple test program.
  (There was a reason to apply this subroutine due the Window 
filenames can be in the "normal" and in UNC formats. The last one is 
quite complex to parse and it was assumed that "_searchenv"  works
well for all cases)

  It sounds that "module" parameter for the 

        else if (path = DynamicPathName(module)) {

must be the filename with no "path" part (under Windows)

  It sounds that under UNIX if the user does supply the relative 
path, that file (share library) will be looked for across ALL 
directories defined with ".rootrc" resource file.  I dont' know 
whether it is "by design". Probably for Load() method would be 
better:

   if (DirName(module))
      i = G__loadfile((char *)module);
   else if (path = DynamicPathName(module)) {
      char *s = ConcatFileName(path, module);
      i = G__loadfile(s);


 Hmm, I've realized TWinNTSystem:DirName() returns "empty" string if 
there is no "path" portion, but UNIX returns the name of the current 
directory instead.

  It seems me to me there is something to sort out here.


  Thank you very much for your report.



        Valery
Dr. Valeri Faine (Valery Fine)
    ------------ -------------   Phone: +41 22 767 4921
CERN                             FAX  : +41 22 767 7155
CH-1211 Geneva, 23               mailto:fine@mail.cern.ch 
Switzerland                      http://nicewww.cern.ch/~fine
                                 



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:21 MET