Hi,
I understand this looks inconsistent, but inevitable (and expected) behavior.
CINT has source file search path control. CINT recognizes the file name with
the name given to CINT API G__loadfile(char* fname) or debugger command .L .
It looks like ROOT also has source file search path control on top of CINT.
And Sometimes what is possible on CINT is not on ROOT. This leads user
confusion. I'll explain following behavior.
>-----------------------------
>but i can't unload this thing:
>-----------------------------
>
>root> .files
> .
> 10 fp=0x 0 lines=0file="/home/cdfsg5/d6/bdata/lacunza/root/test5/./test5.so
"
I guess you typed in test5.so only. "/home/cdfsg5/d6/bdata/lacunza/root/test5"
prefix is added by ROOT. CINT recognizes the file only with the long name
"/home/cdfsg5/d6/bdata/lacunza/root/test5/./test5.so" which is given from ROOT
.
>root> gSystem->Unload("test5.so")
>Warning in <TUnixSystem::UnixDynUnload>: CINT does not support unloading
>shared libs
This says that ROOT recognizes test5.so but because of some reason, it can
not unload the shared lib. I think this limitation comes from ROOT.
>root> G__unloadfile("test5.so")
>Error: G__unloadfile() File "test5.so" not loaded FILE:/var/tmp/baaa006Jw
>(int)(-1)
>*** Interpreter error recovered ***
This says CINT does not recognize test.so because source path prefix is added
by ROOT.
>root> G__unloadfile("./test5.so")
>Error: G__unloadfile() File "./test5.so" not loaded FILE:/var/tmp/caaa006Jw
>LINE:1
>(int)(-1)
>*** Interpreter error recovered ***
CINT does not recognize this case either.
>root> G__unloadfile("/home/cdfsg5/d6/bdata/lacunza/root/test5/./test5.so")
>(int)(-1) <<<< This was a bug. I fixed this.
Cint recognizes the "/home/cdfsg5/d6/bdata/lacunza/root/test5/./test5.so"
and unloaded it. (Return value (-1) was my bug. I fixed this.)
Masaharu Goto
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET