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

Valery Fine (fine@mail.cern.ch)
Wed, 15 Oct 1997 21:15:38 +0100


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