20090609-cvs bad on linux (build fail cygwin)

20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

I built the current cvs head code on linux (fedora 8) OK (target arm) 
but when I run it I see nothing useful in the main "Source Window". I 
can set breakpoints, step, continue and stop but I never see the green 
highlight marker for the current position. Assembly and Mixed views show 
an empty screen.

Gdb low-level control works fine in the "Console Window".

Before I was running the release 6.8 which worked OK. I will go back to it.

Also, after unsuccessful build in cygwin with -mno-cygwin (mingw) and 
under msys shell (also mingw) I tried a straight cygwin build. It went a 
lot farther but eventually got this error:

make[3]: Entering directory 
`/cygdrive/c/insight_make/insight_build/tcl/cygwin'
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE=\"libtcl_cygwin\" -DVERSION=\"8.4\" -DHAVE_GETCWD=1 
-DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 
-DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DUSE_TERMIOS=1 
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ST_BLKSIZE=1 
-DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DNEED_MATHERR=1 -DRETSIGTYPE=void 
-DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_TM_ZONE=1 -I. 
-I../../../insight_sources/tcl/cygwin 
-I../../../insight_sources/tcl/cygwin/../generic 
-DTCL_LIBRARY='"/usr/local//lib"' -g -O2 -mno-win32  -c 
../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c
../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
missing terminating " character
../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
parse error before ')' token
../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
missing terminating " character
../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
parse error before ';' token

I will try official release 6.8 under cygwin and/or mingw. It is 
reported to work.

-gene

Re: 20090609-cvs bad on linux (build fail cygwin)

[Keith Seitz]

Gene Smith wrote:
> I built the current cvs head code on linux (fedora 8) OK (target arm) 
> but when I run it I see nothing useful in the main "Source Window". I 
> can set breakpoints, step, continue and stop but I never see the green 
> highlight marker for the current position. Assembly and Mixed views show 
> an empty screen.

I have been using 20090605-cvs in my daily work (on F10 -- using system 
Tcl, Tk, etc), and I have not noticed your problems. Are you using the 
supplied versions of Tcl or the system versions? [i.e., Are src/tcl, 
src/tk, and src/itcl in your source tree?]

Try opening the debug window or enable logging (see the README). That 
might provide some "insight" into what may be going wrong.

Remind me: what's your target's triple? arm-what? What target are you 
using to run executables, simulator, a board?

Out of curiosity, if you open a console window in insight (when your 
target is stopped at a breakpoint) and type "tk 
gdb_target_has_execution" what does it return?

> Also, after unsuccessful build in cygwin with -mno-cygwin (mingw) and 
> under msys shell (also mingw) I tried a straight cygwin build. It went a 
> lot farther but eventually got this error:

I have never used mingw; I am glad you tried this under cygwin...

Tonight I updated to CVS HEAD and rebuilt the whole thing. It took 
several hours (I only have a 500MHz Pentium III that runs Win2k -- I 
*really* got to set up a virtualized host!), but my build succeeded.

I updated my cygwin installation immediately prior to configuring, 
building, and installing:

$ CFLAGS="-g" ../src/configure 
--prefix=/home/keiths/sources/insight/head/built
[snip]
$ make all-gdb install-gdb
[snip]

[I set the CFLAGS to "-g" so that I can debug the resultant executable, 
if I need to. You need not specify it.]

There must be something magical about my machine that it works every 
time... :-P

> make[3]: Entering directory 
> `/cygdrive/c/insight_make/insight_build/tcl/cygwin'
> gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE=\"libtcl_cygwin\" -DVERSION=\"8.4\" -DHAVE_GETCWD=1 
> -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 
> -DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DUSE_TERMIOS=1 
> -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ST_BLKSIZE=1 
> -DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DNEED_MATHERR=1 -DRETSIGTYPE=void 
> -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_TM_ZONE=1 -I. 
> -I../../../insight_sources/tcl/cygwin 
> -I../../../insight_sources/tcl/cygwin/../generic 
> -DTCL_LIBRARY='"/usr/local//lib"' -g -O2 -mno-win32  -c 
> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c
> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
> missing terminating " character
> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
> parse error before ')' token
> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
> missing terminating " character
> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
> parse error before ';' token

Line 66 of tclUnixInit.c is (and the accompanying comment):

/*
  * Directory in which to look for packages (each package is typically
  * installed as a subdirectory of this directory).  The symbol is
  * defined by Makefile.
  */

static char pkgPath[sizeof(TCL_PACKAGE_PATH)+200] = TCL_PACKAGE_PATH;

What does your Makefile say the value of TCL_PACKAGE_PATH is? In my 
build (cygwin/Makefile), this is defined:

TCL_PACKAGE_PATH = NONE/lib /home/keiths/insight/head/built/lib

I configured with --prefix=/home/keiths/insight/head/built, so this 
looks okay. Right below this is the Makefile portion that uses this:

AM_CFLAGS = -DTCL_LIBRARY='"$(TCL_LIBRARY)"' 
-DTCL_PACKAGE_PATH='"$(TCL_PACKAGE_PATH)"'

Does this look the same in your Makefile?

For this file on my cygwin box, the following build command was executed:

gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE=\"libtcl_cygwin\" -DVERSION=\"8.4\" -DHAVE_GETCWD=1 
-DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 
-DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DUSE_TERMIOS=1 
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ST_BLKSIZE=1 
-DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DNEED_MATHERR=1 -DRETSIGTYPE=void 
-DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_TM_ZONE=1 -I. 
-I../../../src/tcl/cygwin  -I../../../src/tcl/cygwin/../generic 
-DTCL_LIBRARY='"/home/keiths/sources/insight/head/built/share/tcl8.4"' 
-DTCL_PACKAGE_PATH='"NONE/lib 
/home/keiths/sources/insight/head/built/lib"' -g -mno-win32  -c 
../../../src/tcl/cygwin/../unix/tclUnixInit.c

As you can see, both our builds have the define for TCL_LIBRARY (in your 
build it is not set correctly for some reason -- this value is generated 
by configure), yet only my build defines TCL_PACKAGE_PATH -- in yours it 
is missing for some reason. Did you paste the entire command?

Keith

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

Keith Seitz wrote:
> Gene Smith wrote:
>> I built the current cvs head code on linux (fedora 8) OK (target arm) 
>> but when I run it I see nothing useful in the main "Source Window". I 
>> can set breakpoints, step, continue and stop but I never see the green 
>> highlight marker for the current position. Assembly and Mixed views 
>> show an empty screen.
> 
> I have been using 20090605-cvs in my daily work (on F10 -- using system 
> Tcl, Tk, etc), and I have not noticed your problems. Are you using the 
> supplied versions of Tcl or the system versions? [i.e., Are src/tcl, 
> src/tk, and src/itcl in your source tree?]

Yes they are.

> 
> Try opening the debug window or enable logging (see the README). That 
> might provide some "insight" into what may be going wrong.

Right now on linux I have gone back to 6.8 which runs OK. (Right now I 
am experimenting with a i686-pc-ming32 cross build of Insight on linux, 
which is another subject :) )

> 
> Remind me: what's your target's triple? arm-what? What target are you 
> using to run executables, simulator, a board?

I am following the Codesourcery convention: arm-none-eabi.  They provide 
a build of arm-none-eabi-gdb/gdbtui but not arm-none-eabi-insight.

> 
> Out of curiosity, if you open a console window in insight (when your 
> target is stopped at a breakpoint) and type "tk 
> gdb_target_has_execution" what does it return?

(gdb) tk gdb_target_has_execution
1

However, this is with the mingw32 build of 6.8: Per help:
This GDB was configured as "--host=i386-pc-mingw32 --target=arm-none-eabi

> 
>> Also, after unsuccessful build in cygwin with -mno-cygwin (mingw) and 
>> under msys shell (also mingw) I tried a straight cygwin build. It went 
>> a lot farther but eventually got this error:
> 
> I have never used mingw; I am glad you tried this under cygwin...
> 
> Tonight I updated to CVS HEAD and rebuilt the whole thing. It took 
> several hours (I only have a 500MHz Pentium III that runs Win2k -- I 
> *really* got to set up a virtualized host!), but my build succeeded.
> 
> I updated my cygwin installation immediately prior to configuring, 
> building, and installing:
> 
> $ CFLAGS="-g" ../src/configure 
> --prefix=/home/keiths/sources/insight/head/built
> [snip]
> $ make all-gdb install-gdb
> [snip]
> 
> [I set the CFLAGS to "-g" so that I can debug the resultant executable, 
> if I need to. You need not specify it.]
> 
> There must be something magical about my machine that it works every 
> time... :-P

It may just be your --prefix (see below) ??

> 
>> make[3]: Entering directory 
>> `/cygdrive/c/insight_make/insight_build/tcl/cygwin'
>> gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
>> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
>> -DPACKAGE=\"libtcl_cygwin\" -DVERSION=\"8.4\" -DHAVE_GETCWD=1 
>> -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 
>> -DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DUSE_TERMIOS=1 
>> -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ST_BLKSIZE=1 
>> -DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DNEED_MATHERR=1 -DRETSIGTYPE=void 
>> -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_TM_ZONE=1 -I. 
>> -I../../../insight_sources/tcl/cygwin 
>> -I../../../insight_sources/tcl/cygwin/../generic 
>> -DTCL_LIBRARY='"/usr/local//lib"' -g -O2 -mno-win32  -c 
>> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c
>> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
>> missing terminating " character
>> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
>> parse error before ')' token
>> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
>> missing terminating " character
>> ../../../insight_sources/tcl/cygwin/../unix/tclUnixInit.c:66: error: 
>> parse error before ';' token
> 
> Line 66 of tclUnixInit.c is (and the accompanying comment):
> 
> /*
>  * Directory in which to look for packages (each package is typically
>  * installed as a subdirectory of this directory).  The symbol is
>  * defined by Makefile.
>  */
> 
> static char pkgPath[sizeof(TCL_PACKAGE_PATH)+200] = TCL_PACKAGE_PATH;
> 
> What does your Makefile say the value of TCL_PACKAGE_PATH is? In my 
> build (cygwin/Makefile), this is defined:
> 
> TCL_PACKAGE_PATH = NONE/lib /home/keiths/insight/head/built/lib
> 
> I configured with --prefix=/home/keiths/insight/head/built, so this 
> looks okay. Right below this is the Makefile portion that uses this:
> 
> AM_CFLAGS = -DTCL_LIBRARY='"$(TCL_LIBRARY)"' 
> -DTCL_PACKAGE_PATH='"$(TCL_PACKAGE_PATH)"'
> 
> Does this look the same in your Makefile?
> 
> For this file on my cygwin box, the following build command was executed:
> 
> gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE=\"libtcl_cygwin\" -DVERSION=\"8.4\" -DHAVE_GETCWD=1 
> -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 
> -DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DUSE_TERMIOS=1 
> -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ST_BLKSIZE=1 
> -DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DNEED_MATHERR=1 -DRETSIGTYPE=void 
> -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_TM_ZONE=1 -I. 
> -I../../../src/tcl/cygwin  -I../../../src/tcl/cygwin/../generic 
> -DTCL_LIBRARY='"/home/keiths/sources/insight/head/built/share/tcl8.4"' 
> -DTCL_PACKAGE_PATH='"NONE/lib 
> /home/keiths/sources/insight/head/built/lib"' -g -mno-win32  -c 
> ../../../src/tcl/cygwin/../unix/tclUnixInit.c
> 
> As you can see, both our builds have the define for TCL_LIBRARY (in your 
> build it is not set correctly for some reason -- this value is generated 
> by configure), yet only my build defines TCL_PACKAGE_PATH -- in yours it 
> is missing for some reason. Did you paste the entire command?

I think so.

Right now (6.8/-mno-cygwin build) With grep, I only see:
./tcl/win/tclConfig.sh:TCL_PACKAGE_PATH=''
and i see nothing when I grep for DTCL_LIBRARY.

But I will need to try again a head pure cygwin build to compare apples 
to apples. See more below:

> 
> Keith
> 

Keith,
Going back to windows/cygwin I was able to build 6.8 and run insight 6.8 
OK (pure cygwin, no mingw). Then I tried 6.8 on msys shell and it stops 
pretty quick due to and error about MAKEINFO being missing or wrong 
version. So I tried again under cygwin with -mno-cygwin and finally got 
it make/install and run OK. Here is how I built it under cygwin as a 
mingw32 executable:

insight_make
	insight_sources
		unpacked insight-6.8 tarball
	insight_build (directory)
	makeInsight.sh

makeInsight.sh (run from insight_make)looks like this:

#!/bin/sh
export TARGET=arm-none-eabi
export PREFIX=/cygdrive/c/Progra~1/Raisonance/Ride/arm-gcc
export PATH=$PATH:$PREFIX/bin
export PATH=$PATH:$PREFIX/$TARGET

#cd insight_build && rm -rf *
#../insight_sources/configure -v --quiet --prefix=$PREFIX \
#   --target=$TARGET --enable-interwork --enable-multilib \
#   --with-gnu-ld --with-gnu-as
#make all
cd insight_build
../insight_sources/configure -v --quiet --prefix=$PREFIX \
    --target=$TARGET --enable-interwork --enable-multilib \
    --with-gnu-ld --with-gnu-as \
    --host=i686-pc-mingw32 --build=i686-pc-cygwin \
    CC="gcc -mno-cygwin" AR="ar"
make
make install
<eof>

When building for pure cygwin I leave off the last two lines of the 
configure command. This is loosely based on some insight build scripts 
provided by this guy:
http://openhardware.net/Embedded_ARM/Toolchain/

I have not tried this again with the cvs head with this exact setup. I 
don't know how important the --prefix setting is during the make stage. 
I thought it was only used during "make install" but not sure. That may 
be why my TCL_LIBRARY was pointing to the wrong place since I may have 
had the prefix pointing somewhere else when I was building the head?

(Build on cygwin on my fairly fast machine takes a couple hours. Build 
on msys seems like it would be much faster if I could get past the 
MAKEINFO/textinfo error.)

-gene

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

Gene Smith wrote:
  > Going back to windows/cygwin I was able to build 6.8 and run insight 
6.8
> OK (pure cygwin, no mingw). Then I tried 6.8 on msys shell and it stops 
> pretty quick due to and error about MAKEINFO being missing or wrong 
> version. So I tried again under cygwin with -mno-cygwin and finally got 
> it make/install and run OK. Here is how I built it under cygwin as a 
> mingw32 executable:
> 
> insight_make
>     insight_sources
>         unpacked insight-6.8 tarball
>     insight_build (directory)
>     makeInsight.sh
> 
> makeInsight.sh (run from insight_make)looks like this:
> 
> #!/bin/sh
> export TARGET=arm-none-eabi
> export PREFIX=/cygdrive/c/Progra~1/Raisonance/Ride/arm-gcc
> export PATH=$PATH:$PREFIX/bin
> export PATH=$PATH:$PREFIX/$TARGET
> 
> #cd insight_build && rm -rf *
> #../insight_sources/configure -v --quiet --prefix=$PREFIX \
> #   --target=$TARGET --enable-interwork --enable-multilib \
> #   --with-gnu-ld --with-gnu-as
> #make all
> cd insight_build
> ../insight_sources/configure -v --quiet --prefix=$PREFIX \
>    --target=$TARGET --enable-interwork --enable-multilib \
>    --with-gnu-ld --with-gnu-as \
>    --host=i686-pc-mingw32 --build=i686-pc-cygwin \
>    CC="gcc -mno-cygwin" AR="ar"
> make
> make install
> <eof>
> 

I tried this again on cygwin using your CVS head code. For some reason 
it could not find a header file in insight_sources/tk/win when making 
libgui module. The search path in libgui/src/Makefile only pointed into 
tk/unix. So I manually changed the TK_INCLUDES macro in Makefile to 
include the win path:

TK_INCLUDES = -I/cygdrive/c/insight_make/insight_sources/tk/generic \ 
-I/cygdrive/c/insight_make/insight_sources/tk/win \  <--new
-I/cygdrive/c/insight_make/insight_sources/tk/unix

I don't know how configure sets this up. Maybe it doesn't realize this 
is a "win" build and should use the win includes instead of (or before) 
unix...??

Also, and this is not specifc to cvs HEAD, I frequently see this 
corruption in the generated Makefiles (looking with vim):

program_transform_name = s,^,arm-none-eabi^M-

I think maybe sed is doing this putting an extraneous newline or end of 
line character in when it is inserting a dash character. Maybe the 
cygwin sed is assumes dos style line endings, cr/lf ???. If I remove the 
^M and and make or make install again it is OK.

In this case the offending files were Makefiles under 
insight_build/sim/. Also, several Makefiles under insight_build/gdb had 
this problem. It detected the error during "make install" phase. All the 
Makesfiles that had to be modifed were unix according to vim.

I don't see this ^M problem building the same files with linux.

Ok, after fixing the ^M errors it installs OK and run as a windows "MZ" 
exe. But it has the exact same problem I saw on linux: no functionality 
in the main code frame display area. But the buttons at the top work OK.

I can still control gdb witht eh Console Window. Stopped at a bp I see 
this, as you asked about:

(gdb) tk gdb_target_has_execution
1

However, don't know what you mean by this:

"Try opening the debug window or enable logging (see the README). That 
might provide some "insight" into what may be going wrong."

FWIW, the register window seems to work but don't see a "debug" window. 
Also, nothing in the top level README about logging. Is this a configure 
option? (To reconfigure and build on my system also takes forever. :))

Also, you say:
"I have been using 20090605-cvs in my daily work (on F10 -- using 
*system* [my emphasis]  Tcl, Tk, etc), and I have not noticed your 
problems. Are you using the supplied versions of Tcl or the system 
versions? [i.e., Are src/tcl, src/tk, and src/itcl in your source tree?]"

When you say using "system" Tcl/Tk etc, do you mean the tcl/tk etc not 
included with insight? On windows, as far as I know, insight provides 
the only tcl, tk. How do you control which is used by insight? (On my 
linux there is an installed system tcl, tk in /usr somewhere.)

-gene

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

Gene Smith wrote, On 06/10/2009 12:08 PM:
> I built the current cvs head code on linux (fedora 8) OK (target arm)
> but when I run it I see nothing useful in the main "Source Window". I
> can set breakpoints, step, continue and stop but I never see the green
> highlight marker for the current position. Assembly and Mixed views show
> an empty screen.
>
> Gdb low-level control works fine in the "Console Window".
>
> Before I was running the release 6.8 which worked OK.
>

Build of cvs head on f11 x86_64 has the exact same problem (no responses 
in source window). So now I see the same CVS head problem with f8, f11 
and on windows.

I tried installing in a virgin location on f11 since the previous 6.8 
install might have been affecting it (there is no make uninstall). But 
it made no difference.

On all platforms, 6.8 builds (with the same script) and runs fine.
-gene

Re: 20090609-cvs bad on linux (build fail cygwin)

[Keith Seitz]

Gene Smith wrote:

> On all platforms, 6.8 builds (with the same script) and runs fine.

I hate to say this, but this leads me to believe that a change in gdb is 
actually breaking insight. Insight has not changed much (if at all) in 
the last year or two. So there must be something under the covers, and 
that means gdb.

If you can supply me with a detailed build and test procedures to 
reproduce the problem, I'll see if I can figure out what is going wrong.

Keith

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

Keith Seitz wrote:
> Gene Smith wrote:
> 
>> On all platforms, 6.8 builds (with the same script) and runs fine.
> 
> I hate to say this, but this leads me to believe that a change in gdb is 
> actually breaking insight. Insight has not changed much (if at all) in 
> the last year or two. So there must be something under the covers, and 
> that means gdb.
> 
> If you can supply me with a detailed build and test procedures to 
> reproduce the problem, I'll see if I can figure out what is going wrong.
> 
> Keith
> 

But I thought insight has it *own* gdb that never changes? Anyhow, here
are the step I use to build it:

mkdir insight_make
cd insight_make
copy in attachment environ.sh
copy in attachment 05makeInsight.sh
copy in attachment 05instInsight.sh
(adjust paths in scripts as appropriate)
mkdir insight_build
bring in cvs head (I think it is under src/ by default) and rename to 
insight_sources:
	mv src/ insight_sources/
./05makeInsight
./05instInsight

That's it. However, to actually see the problem you need to be able to 
bring up source window that actually attempts to do something, like step 
through code or hit a set breakpoint. The non-responsiveness of the 
source window (other than the command menu and icons at the top) is the 
problem.

Hopefully, this will help.

Thanks,
-gene
P/S: I am still a bit confused as to whether I should be using the 
"system" supplied tcl/tk or the tcl/tck code from insight. I think I am 
using insight's. If I should use the system tcl/tk, how do I do that?



[-- Attachment #2: environ.sh --]
[-- Type: text/plain, Size: 281 bytes --]

#export TARGET=arm-rtems4.9
#export PREFIX=/opt/rtems-4.9
#export PATH=$PATH:$PREFIX/bin
export TARGET=arm-none-eabi
export PREFIX=/home/gene/eabi/install
export PATH=$PATH:$PREFIX/bin

## special for linux mingw32 cross compile, n/a otherwise
export RC="i686-pc-mingw32-windres"


[-- Attachment #3: 05makeInsight.sh --]
[-- Type: text/plain, Size: 673 bytes --]

#!/bin/sh
#
# gds: reduce configure prms to rtems default (didn't help) 
#
. ./environ.sh
if [[ "$TARGET" == ""  || "$PREFIX" == "" ]] ; then
	echo "You need to set: TARGET and PREFIX"; exit 0;
fi
export PATH=$PATH:$PREFIX/$TARGET

#cd insight_build && rm -rf *
#../insight_sources/configure -v --quiet --prefix=$PREFIX \
#   --target=$TARGET --enable-interwork --enable-multilib \
#   --with-gnu-ld --with-gnu-as
#make all 
cd insight_build 
../insight_sources/configure -v --quiet --prefix=$PREFIX \
   --target=$TARGET --enable-interwork --enable-multilib \
   --with-gnu-ld --with-gnu-as 
#   --host=i686-pc-mingw32 --build=i686-pc-linux-gnu

make
#make install
cd ..


[-- Attachment #4: 05instInsight.sh --]
[-- Type: text/plain, Size: 215 bytes --]

#!/bin/sh
. ./environ.sh
if [[ "$TARGET" == ""  || "$PREFIX" == "" ]] ; then
	echo "You need to set: TARGET and PREFIX"; exit 0;
fi
export PATH=$PATH:$PREFIX/$TARGET
cd insight_build 
#make all 
make install
cd ..

Re: 20090609-cvs bad on linux (build fail cygwin)

[Keith Seitz]

Gene Smith wrote:
> But I thought insight has it *own* gdb that never changes? Anyhow, here
> are the step I use to build it:

No, it does not. Insight CVS uses gdb CVS. Insight 6.8 uses gdb 6.8. It 
has its own versions of tcl, tk, itcl, etc, but those are now just 
copies of some release (currently 8.4, I think). Except on cygwin, I do 
not use the supplied versions of tcl et al anymore. I use the 
system-supplied versions on Fedora.

Kevin Buettner is working on updating tcl et al CVS on sourceware to the 
latest release.

> Hopefully, this will help.

I will give this a go by the end of the week.

> P/S: I am still a bit confused as to whether I should be using the 
> "system" supplied tcl/tk or the tcl/tck code from insight. I think I am 
> using insight's. If I should use the system tcl/tk, how do I do that?

You can use whatever version you would like to. It has been a goal of 
mine (for quite some time sadly) to eliminate our dependence on a 
sourceware-supplied tcl/tk/itcl. That requirement originally came in the 
days of Tcl 8.1, when we carried a bunch of local patches to Tcl. We 
didn't upgrade sourceware Tcl until 8.4 (or was it 8.3?) and our 
supplied version of Tcl became identical to upstream.

A little while ago, I got around to eliminating the requirement for 
sourceware-supplied Tcl. But it remains for historical reasons (and 
because cygwin still requires it). If we got cygwin "fixed", I guess we 
could just simply eliminate it altogether from the repo if no other 
project was using it.

Keith

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

Keith Seitz wrote:
> Gene Smith wrote:
>> But I thought insight has it *own* gdb that never changes? Anyhow,
>> here are the step I use to build it:
>
> No, it does not. Insight CVS uses gdb CVS. Insight 6.8 uses gdb 6.8.
 > It has its own versions of tcl, tk, itcl, etc, but those are now just
 > copies of some release (currently 8.4, I think). Except on cygwin, I > do
 > not use the supplied versions of tcl et al anymore. I use the
 > system-supplied versions on Fedora.
>
> Kevin Buettner is working on updating tcl et al CVS on sourceware to
 > the latest release.
>
>> Hopefully, this will help.
>
> I will give this a go by the end of the week.
>
>> P/S: I am still a bit confused as to whether I should be using the
 >> "system" supplied tcl/tk or the tcl/tck code from insight. I think I 
 >> am using insight's. If I should use the system tcl/tk, how do I do 
 >> that?
>
> You can use whatever version you would like to. It has been a goal
> ofmine (for quite some time sadly) to eliminate our dependence on a
 > sourceware-supplied tcl/tk/itcl. That requirement originally came in 
 > the days of Tcl 8.1, when we carried a bunch of local patches to Tcl. 
 > We didn't upgrade sourceware Tcl until 8.4 (or was it 8.3?) and our
 > supplied version of Tcl became identical to upstream.
>
> A little while ago, I got around to eliminating the requirement for
 > sourceware-supplied Tcl. But it remains for historical reasons (and
 > because cygwin still requires it). If we got cygwin "fixed", I guess 
 > we could just simply eliminate it altogether from the repo if no other
 > project was using it.

I think winavr project distributes a mingw build of insight. I am pretty
sure mingw has no "system" tcl/tk. However, I don't think many (or any?)
winavr or users use it.

>
> Keith

Thanks for explaining all this! Now I see.
But since you didn't tell me how to select "system" tcl/tk vs. built-in
I assume you don't think that is related to my problem.

Re: 20090609-cvs bad on linux (build fail cygwin)

[Gene Smith]

(The last two exchanges never got to the list, I just added them.
  -gene )
Gene Smith wrote:

 > I think winavr project distributes a mingw build of insight. I am > 
 >pretty sure mingw has no "system" tcl/tk. However, I don't think many 
 >(or any?) winavr or users use it.

I didn't know that... Yeah, I suspect Tcl/Tk will just stay in 
sourceware for a while. Red Hat still uses it, too, I think.

 > But since you didn't tell me how to select "system" tcl/tk vs. 
 >built-in I assume you don't think that is related to my problem.

Sorry -- I missed that. To build using the system-supplied tcl/tk, make 
sure you have the dev packages (on linux) installed: tcl-devel, 
tk-devel, itcl-devel, itk-devel. Remove (or rename) tcl, tk, and itcl 
from your source directory, and the build will find the system-installed 
versions. [I don't recall if this is absolutely necessary, but I do it 
anyway.]

When starting an untested build configuration for the first time, I 
usually do a "make configure-gdb" and check the output of configure that 
it found the tcl/tk/itcl/itk stuff that I expected it to.

Keith