[Ktechlab-devel] Another odd issue with gpsim on OSX.

[David Saxton]

On Friday 03 March 2006 07:48, Bryn Davies wrote:
>   Seems to have an issue with not recognising any supported chips -
> this leads to a variety of odd errors in kTechLab along the lines of
> "problem with cod file".  Mikey Sklar ( <sklarm at electric-
> clothing.com> ) has a patch that seems to fix this behavior, at least
> in my case, bundled with his fink builds of gpsim 0.21.11:
>
> --8<-cut here-8<--
>
> --- gpsim-0.21.11/src/processor.cc      2005-10-01 17:12:55.000000000
> -0400
> +++ gpsim-0.21.11-cvs/src/processor.cc  2005-10-08 08:17:04.000000000
> -0400
> @@ -1970,7 +1970,7 @@
>     return cpu_constructor();
> }
> -ProcessorConstructorList * ProcessorConstructor::processor_list =
> new ProcessorConstructorList();
> +ProcessorConstructorList * ProcessorConstructor::processor_list;
> ProcessorConstructorList * ProcessorConstructor::GetList() {
>     if(processor_list == NULL) {
>
> --8<-cut here-8<--
>
>   If non-mac people try this out and it doesn't cause problems for
> other people, perhaps it could be folded into the patch on the
> ktechlab web page?

"ProcessorConstructorList * ProcessorConstructor::processor_list;"

This the new line looks a bit dodgy. As far as I know, the processor_list 
pointer will only be null if the computer memory was previously zero before 
being used by gpsim. So it might work occasionally, but only by luck...

A better line would be

"ProcessorConstructorList * ProcessorConstructor::processor_list = 0;"

>   Also, very happy to see my patch find it's way into SVN, but it
> would be nice if I could figure out a way to make configure set -
> DDARWIN automatically.  Sadly, I don't know much about configure. :-(

Fixed that issue, via use of the header file qglobal.h. Could you test it out 
to make sure that it's detecting darwin ok? :)

David