Hi everyone,
I've just compiled BRAT v1.4 on Linux here at NBI, and I have no
problems doing `.x BratLoad.C'!
On Tue, 01 Feb 2000 12:03:57 -0600 Kris Hagel <hagel@comp.tamu.edu> wrote:
> Hello,
> I have been beating myself crazy in the last day on these problems. It
> started with Yury reporting a problem similar to what you (Ian) indicates
> from his own account where you cannot load libBrat_Tof.so because of the
> undefined symbol BrBaseMonitor.
About symbols, I have a few remarks. When you see a message like
dlopen error: <lib> undefined symbol: <symbol>
try to do
> nm <lib> | cat -n | grep <symbol>
Notice the first number. This is the line number of your symbol. Then
do a `demangled' nm
> nm -C libBrat_Base.so | cat -n | grep <number>
and there is you `real' C++ method name. In Ians second case (see
below), this would be
> nm libBrat_Tof.so | cat -n | grep Draw__13BrBaseMonitorPCc
440 U Draw__13BrBaseMonitorPCc
> nm -C libBrat_Tof.so | cat -n | grep 440
198 0002440f t .LM198
440 U BrBaseMonitor::Draw(char const *)
622 0001e440 t G__BrMonitorTof_ImplFileName_0_1__FP8G__valuePCcP8G__parami
Hence the method we are looking for is `BrBaseMonitor::Draw(char const
*)' which _is_ undefined (the `U' in front). This makes it easier to
refer to undefined symbols, when sending mails, etc.
> This is fixed by loading
> libBrat_Monitor.so right after loading libBrat_Base.so That worked for
> Yury.
This doesn't seem to be the problem on the NBI
computers. libBrat_Monitor.so is loaded several loads later after
libBrat_Base.so.
> This also points to why pro and new are now pointing to the same (I know,
> should have sent out a message; will the next time; mea culpa etc etc
> etc).
Yeah, you should have sent a message. And you should have tag'ed the
CVS checkin, as you apparently have moved BRAT up to version 1.4. Do
please remember to do this. It makes it easier for us to talk about
problems, etc. I actually suggest you tag quite often, using a schema
of the numbers (like `VER-1-4-89'). In that way, we're not gonna be
talking of different versions of code.
> The problem is reminiscent
> of two things I have seen with root/brat. One is when root is compiled
> with a different compiler than used with brat.
You should _always_ compile you BRAT and ROOT with the same compiler
_major_ version, but there is no reason why you should insist on the
same _minor_ number. Symbols should _always_ be resovled properly
within the same compiler major version.
> The other is when paths
> are not correct.
The most likely. Check if you have an old BratLoad.C lying around
somewhere, or you're not accidently using old BRAT or ROOT libraries
(check your ROOT.Dynamic.Path in .rootrc!)
> So I am really confused and
> cursing linux etc.
It has nothing to do with Linux Kris, I'm sure of it!
> Ian Bearden wrote:
>
> > Dear all,
> > If I try the same from my own account on the pii machines, I get
> > dlopen error: /home/brahmlib/brat/pro/lib/linux/libBrat_Tof.so:
> > undefined symbol: Draw__13BrBaseMonitorPCc
> > Load Error: Dynamic link library
> > /home/brahmlib/brat/pro/lib/linux/libBrat_Tof.so can not load
> >
> > I also note that are brat/pro and brat/new the same and were both made
> > yesterday. Should one not wait a bit before moving the latest stuff
> > to pro?
Yeah, that's my instinct too!
Cheers,
Christian Holm Christensen
______________________________________________________________________
Address: Phone: (+45) 35 35 96 91
Sankt Hansgade 23, 1. th. Office: (+45) 353 25 307
DK-2200 Copenhagen N Web: www.nbi.dk/~cholm
Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Tue Feb 01 2000 - 20:35:05 EST