Re: Using system tcl/tk version 8.5

[Keith Seitz <keiths at redhat dot com>]

On 03/19/2010 10:33 PM, Gene Smith wrote:
> Well, it runs and I can almost debug. (I renamed them to 8.4 to get it
> to link then changed the names back to 8.5 to run insight.)

This sounds like something very unexpected happened. The build must have 
found the wrong versions of the libraries.

> I just tried with the real system and openocd server. It runs but is
> weird. Sometimes won't step. Keyboard doesn't work in dialogs. Radio
> buttons are all highlighted and can't select things. Some strange icons
> buttons (a movie camera?). Fonts don't look good.

This is *very* odd. I've never seen this. Could you try starting up with 
"-nx" to suppress reading the preferences file. Does that get you any 
further? [I don't think this patch is entirely correct, BTW, but 
probably close.]

Can you tell me the entire build procedure you used?

I can build insight for x86_64/64-bit, but the register window will 
crash insight. I will look into that. Otherwise, dialogs all behave 
normally, I can step, browse the stack, inspect variables, and 
everything else. Only problem I found was the register window.

[For the record, I did this with: 'CFLAGS="-m64" ../src/configure 
--enable-64-bit-bfd'. Don't know if that is 100% correct, but it works 
better than what you've got! :-/]

> I had to specify both. Specifically I had to say:
>
> --with-tcl=/usr/lib64 --with-tk=/usr/lib64
>
> (Without the --with-tk it "couldn't find private tk headers")
>
> After doing this, still no improvement in how it runs. It doesn't crash
> but it is basically unusable. Maybe because of 64 bits? I assume I would
> need the 32 bit tk/tcl-devel packages to build for 32 bits.

I don't have a lot of experience with 64-bit vs 32-bit, but I would 
guess that mixing 32-bit and 64-bit would be bad. Maybe even very bad. 
What does "ldd" of your insight executable say? Does it mix 32-bit and 
64-bit?

For the record, mine says:

$ ldd insight
	linux-vdso.so.1 =>  (0x00007fff64dff000)
	libtk8.5.so => /usr/lib64/libtk8.5.so (0x000000346c400000)
	libtcl8.5.so => /usr/lib64/libtcl8.5.so (0x0000003854e00000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x000000346b800000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003553000000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003552c00000)
	libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003430600000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003553800000)
	libpython2.5.so.1.0 => /usr/lib64/libpython2.5.so.1.0 (0x0000003569600000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x000000346c000000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003552800000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003565e00000)
	libXft.so.2 => /usr/lib64/libXft.so.2 (0x0000003473a00000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x000000346d800000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x000000346c800000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00000036bb000000)
	libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x000000346b400000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x000000346bc00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003552400000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003553400000)
	libutil.so.1 => /lib64/libutil.so.1 (0x000000355e600000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003556000000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003555c00000)

> At first it kind of worked, but now I can't get it to step through my
> arm cortex-m3 program at all. Been using the old Ins 6.8 (with kluges to
> make it build). Just wanted to try the lastest again. 6.8 works well for
> projects except doubles don't display right (floats OK).

Maybe we need to start simple? Can you build the native *only* version? 
Perhaps there is a configury bug w.r.t. cross-toolchains?

> It's the cvs head version. I just got it the other day.

Wow, I am really sorry that you're having so many problems.

Keith