> Unfortunately, I have such a rule in my makefile and I'm sure that the
> code didn't get any old dictionary files laying around. All the
> dictionary files were regenerated with the correct version of cint (I
> picked through the output of make to be sure of this).
>
> The thing I find really puzzling is that I don't get either of these
> errors when running the executables directly.
>
> I've also since tried gdb 5.0 and see the same behavior -- I get strange
> errors when using GDB but not when running the executable directly
>
I recently had a problem with gdb (5.0) with root that might or might not be
related to this one. I tried to switch from "pro" to "new" root versions.
("pro" was 2.22/09, "new" was 2.24/05)
I set ROOTSYS, LD_LIBRARY_PATH, and PATH to point to "new", in my
default shell. Dictionary was remade, everything recompiled, etc.
The executable ran fine outside of gdb (well, not fine actually, but
it ran). Environment variables when checked inside of gdb all pointed
to "new", too.
But then in gdb I got:
/sbin/loader: Fatal Error: cannot map libCore.so
This suggested that gdb was still looking for the shared objects
in the "pro" area, since
"new" links against
/afs/cern.ch/exp/ams/Offline/root/OSF1/new/lib -lNew -lCore -lCint -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lm
and "pro" links against
-L/afs/cern.ch/exp/ams/Offline/root/OSF1/pro/lib -lNew -lBase -lCint -lClib -lCont -lFunc -lGraf -lGraf3d -lHist -lHtml -lMatrix -lMeta -lMinuit -lNet -lPhysics -lPostscript -lProof -lRint -lTree -lUnix -lZip -lm
But I don't understand why gdb was looking in the pro area (??)
gdb worked fine when I set everything back to pro.
This was on OSF1.
Kate Scholberg
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:38 MET