Re: Build for mingw32 and i686 on x86_64 observations

[Keith Seitz <keiths@redhat.com>]

On 03/22/2010 07:47 PM, Gene Smith wrote:
> First off, I want to point out that I can build the very recent cvs head
> for an embedded arm application but it doesn't run correctly in that the
> insight gui does not reflect the actual location of the PC while
> debugging/stepping (the green highlighted line never moves). This is
> regarless of whether the tk/tcl is system supplied or insight's own.

What target did you build for? Your configure options only list --build 
and --host.

Also, what target are you trying to debug under? The problem you 
describe is typically a bug in the target back-end. It would not 
surprise me to find out that something changed in gdb-land that broke 
insight. This happens more often than I would like, but since I only use 
insight natively, unless I can reproduce on a simulator, my bug-solving 
is limited to what I can divine by reading the code.

> But when build with i686-pc-mingw32-gcc toolchain (fedora 12 yum), the
> same (windows specific) kludges as before were required (syntax errors
> in window specific tck/tk code regarding dde and registry that can be
> commented out).

That doesn't surprise me. Our tcl/tk are greatly out of date, and I do 
not have general access to a windows machine. I've never tried building 
a cross from linux, though...

> However, with mingw32 I had to build/install then build/install again to
> get insight.exe to appear at install/bin. It seems that in the install
> directory under lib there needs to exist *at compile time* tkConfig.sh
> and tclConfig.sh. So you have to make clean all, make install, then make
> clean all, make install again when you are starting with an empty
> install directory. So if you keep install/lib/tclConfig.sh and
> tkConfig.sh between compiles (don't completely clean the install dir)
> you are ok the next time.

Configure will look for t{cl,k}Config.sh in the install directory and 
several other places. Wherever it finds those files, the location will 
be hard-coded into configure's cache (if what I am deducing from my 
vague recollection of how this all works is accurate). Your description 
makes sense. That is simply a quirk of how configure works.

Next time, try erasing the gdb directory and forcing a reconfigure.

Keith