Re: BLT Problems

[glen e. p. ropella]

> I made the change to ActiveGraph.m suggested below, and then did a 'make
> clean' and a 'make' in the swarm directory to rebuild the swarm
> libraries, and then did the same in the HeatBugs directory.  I still get
> the same errors.  I should also mention that the graphBug and addHeatbug
> buttons don't see to be working.  When I click on them I just get a beep
> and nothing else happens.  This may indicate that the problems extend
> beyond BLTVector.  Any other suggestions?

I was afraid of that. [grin]

> I think that I've found some more clues to the problem.  First of all, I
> noticed that thought the BLTVector error is the only message that shows
> up on the err.log file when I invoke heatbugs with "./heatbugs >
> err.log", if I watch the xterm windows, I get a whole string of errors
> inlcuding messages like:
> 
>       (tcl -eval:) invalid command name "busy"
>               while executing
>       "unknown_pre_tclObjc $name $args"
> 
> Also, if entirely remove BLT by deleting /usr/local/blt and all of its
> subdirectories I get exactly the same errors.
> 
> Does this mean that swarm is not finding some of the libraries?  I used
> that standard ./configure and make scripts for all of the packages so
> everything should be in the standard places.  Any idea what's up here?

As to the (tcl -eval:) problem, I'm not sure what that's from.  We
could explore that; but, I suspect it's a side-effect of the real
problem.  (FYI, the error is being generated in libtclobjc/tclObjc.m,
in case you would like to use gdb and a breakpoint.)

But, the other symptom is much more intriguing.  You say you delete
the /usr/local/blt directory tree, recompile your heatbugs app, and
everything still runs?  You don't get any unsatisfied references at
compile time?  Are your libBLT.a or libBLT.so files in /usr/local/blt?
This seems unlikely.

It would indicate to me that the problem we're seeing (with the
warning message BLTVector does not respond to "append" and then with
this symptom, too) that you must have a libBLT.[a|so] somewhere else
on your system with which you are linking.  Could you post (or email
me directly so as not to annoy the list) the output from the make
process?  Particularly, the gcc compile and link commands?  You might
also pass along the output from the "% ldd heatbugs" command.  I say
this because even though my system looks like this:

  % ls /usr/local/blt/lib
total 744
drwxr-xr-x   3 root     root         1024 Oct 25 10:59 blt2.1/
-rw-r--r--   1 root     root       404828 Oct 25 10:59 libBLT.a
-rw-r--r--   1 root     root       349094 Oct 25 10:59 libBLT.so.2.1

my executables come out looking like:
  % ldd ../../mousetrap/mousetrap   
        libdl.so.1 => /lib/libdl.so.1.7.14
        libBLT.so.2 => /usr/lib/libBLT.so.2.1
        libtk.so.1 => /usr/lib/libtk.so.1.4.1
        libtcl.so.1 => /usr/lib/libtcl.so.1.7.5
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6.0
        libm.so.5 => /lib/libm.so.5.0.6
        libc.so.5 => /lib/libc.so.5.3.12

which means BLT is installed in both /usr/local/blt/lib and /usr/lib
and the executable wants the one in /usr/lib.

glen