[GRASS-dev] issues with compiling and running GRASS on Mac

cmbarton · September 8, 2008, 3:47am

I just updated from develbranch_6 after a couple of weeks. Here are some remaining problems in compiling and a showstopper with running GRASS.

1) vdigit: compiles fine now. BUT it probably keeps the wxPython GUI from running now (see below).

2) wxnviz: still doesn't compile but gets a bit farther if render.h is removed and make clean, make is run. Here is the error I get now.

cd /Users/cmbarton/grass_dev/grass6_src/lib/nviz
make
...

/Frameworks/UnixImageIO.framework/unix/include -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/render.o -c render.c
render.c: In function ‘Nviz_create_render_window’:
render.c:139: warning: assignment makes pointer from integer without a cast
render.c:146: warning: assignment makes pointer from integer without a cast
render.c: In function ‘Nviz_make_current_render_window’:
render.c:204: error: ‘mac_win’ undeclared (first use in this function)
render.c:204: error: (Each undeclared identifier is reported only once
render.c:204: error: for each function it appears in.)
render.c:204: warning: ‘AGLDrawable’ is deprecated
make: *** [OBJ.i386-apple-darwin9.4.0/render.o] Error 1

3) i.attcorr no longer compiles. Here is the error.

cmb-MBP-2:nviz cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/imagery/i.atcorr
cmb-MBP-2:i.atcorr cmbarton$ make
Makefile:15: warning: overriding commands for target `/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr'
../../include/Make/Module.make:14: warning: ignoring old commands for target `/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr'
c++ -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -arch i386 -Os -g -DPACKAGE=\""grassmods"\" -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/main.o -c main.cpp
main.cpp: In function ‘void process_raster(int, InputMask, ScaleRange, int, int, int, bool, ScaleRange, bool)’:
main.cpp:309: error: ‘isnan’ was not declared in this scope
make: *** [OBJ.i386-apple-darwin9.4.0/main.o] Error 1

4) After make install, GRASS will no longer start up in wxPython. It does the startup screen fine, but bombs when it tries to launch the main layer manager. Here is the error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter not initialized (version mismatch?)

Note that I have changed nothing on my system since the last time it compiled and ran fine.

I suspect that an issue that William Kyngesbury recently mentioned may be the cause. vdigit, which compiles now, may do so incorrectly against the system version of Python (2.5.1) rather than the newer one that is my Python default (2.5.2). If so, the version check in the wxGUI startup kills it.

What is the easiest way to diable vdigit to test this?

Michael

cmbarton · September 8, 2008, 4:55am

Forgot to mention that I tried compiling wxnviz WITH render.h and got the same errors.

Michael

On Sep 7, 2008, at 8:47 PM, Michael Barton wrote:

cd /Users/cmbarton/grass_dev/grass6_src/lib/nviz
make
...

/Frameworks/UnixImageIO.framework/unix/include -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/render.o -c render.c
render.c: In function ‘Nviz_create_render_window’:
render.c:139: warning: assignment makes pointer from integer without a cast
render.c:146: warning: assignment makes pointer from integer without a cast
render.c: In function ‘Nviz_make_current_render_window’:
render.c:204: error: ‘mac_win’ undeclared (first use in this function)
render.c:204: error: (Each undeclared identifier is reported only once
render.c:204: error: for each function it appears in.)
render.c:204: warning: ‘AGLDrawable’ is deprecated
make: *** [OBJ.i386-apple-darwin9.4.0/render.o] Error 1

cmbarton · September 8, 2008, 5:04am

I disabled the vdigit makefile so that it raised and error and didn’t compile. I still get the same error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter not initialized (version mismatch?)

Any idea what is causing this if I have not changed Python or wxPython on my Mac since this last compiled with no problem (25 August).

Michael

Begin forwarded message:

From: Michael Barton <michael.barton@asu.edu>
Date: September 7, 2008 8:47:57 PM GMT-07:00
To: Landa Martin <landa.martin@gmail.com>, grass developers <grass-dev@lists.osgeo.org>, Kyngesburye William <kyngchaos@kyngchaos.com>
Subject: issues with compiling and running GRASS on Mac

I just updated from develbranch_6 after a couple of weeks. Here are some remaining problems in compiling and a showstopper with running GRASS.

vdigit: compiles fine now. BUT it probably keeps the wxPython GUI from running now (see below).

wxnviz: still doesn’t compile but gets a bit farther if render.h is removed and make clean, make is run. Here is the error I get now.

cd /Users/cmbarton/grass_dev/grass6_src/lib/nviz
make
…

/Frameworks/UnixImageIO.framework/unix/include -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/render.o -c render.c
render.c: In function ‘Nviz_create_render_window’:
render.c:139: warning: assignment makes pointer from integer without a cast
render.c:146: warning: assignment makes pointer from integer without a cast
render.c: In function ‘Nviz_make_current_render_window’:
render.c:204: error: ‘mac_win’ undeclared (first use in this function)
render.c:204: error: (Each undeclared identifier is reported only once
render.c:204: error: for each function it appears in.)
render.c:204: warning: ‘AGLDrawable’ is deprecated
make: *** [OBJ.i386-apple-darwin9.4.0/render.o] Error 1

i.attcorr no longer compiles. Here is the error.

cmb-MBP-2:nviz cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/imagery/i.atcorr
cmb-MBP-2:i.atcorr cmbarton$ make
Makefile:15: warning: overriding commands for target /Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr' ../../include/Make/Module.make:14: warning: ignoring old commands for target /Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr’
c++ -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -arch i386 -Os -g -DPACKAGE="“grassmods”" -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/main.o -c main.cpp
main.cpp: In function ‘void process_raster(int, InputMask, ScaleRange, int, int, int, bool, ScaleRange, bool)’:
main.cpp:309: error: ‘isnan’ was not declared in this scope
make: *** [OBJ.i386-apple-darwin9.4.0/main.o] Error 1

After make install, GRASS will no longer start up in wxPython. It does the startup screen fine, but bombs when it tries to launch the main layer manager. Here is the error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter not initialized (version mismatch?)

Note that I have changed nothing on my system since the last time it compiled and ran fine.

I suspect that an issue that William Kyngesbury recently mentioned may be the cause. vdigit, which compiles now, may do so incorrectly against the system version of Python (2.5.1) rather than the newer one that is my Python default (2.5.2). If so, the version check in the wxGUI startup kills it.

What is the easiest way to diable vdigit to test this?

Michael

cmbarton · September 8, 2008, 6:01am

After some tedious detective work, the startup error in wxGUI is caused by the following line in vdigit.py

import _grass6_wxvdigit

This calls _grass6_wxvdigit.so

So back to my first guess, vdigit is compiling with a different version of Python than the rest of GRASS.

Michael

On Sep 7, 2008, at 10:04 PM, Michael Barton wrote:

I disabled the vdigit makefile so that it raised and error and didn’t compile. I still get the same error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter not initialized (version mismatch?)

Any idea what is causing this if I have not changed Python or wxPython on my Mac since this last compiled with no problem (25 August).

Michael

Begin forwarded message:

From: Michael Barton <michael.barton@asu.edu>
Date: September 7, 2008 8:47:57 PM GMT-07:00
To: Landa Martin <landa.martin@gmail.com>, grass developers <grass-dev@lists.osgeo.org>, Kyngesburye William <kyngchaos@kyngchaos.com>
Subject: issues with compiling and running GRASS on Mac

I just updated from develbranch_6 after a couple of weeks. Here are some remaining problems in compiling and a showstopper with running GRASS.

vdigit: compiles fine now. BUT it probably keeps the wxPython GUI from running now (see below).

wxnviz: still doesn’t compile but gets a bit farther if render.h is removed and make clean, make is run. Here is the error I get now.

cd /Users/cmbarton/grass_dev/grass6_src/lib/nviz
make
…

/Frameworks/UnixImageIO.framework/unix/include -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/render.o -c render.c
render.c: In function ‘Nviz_create_render_window’:
render.c:139: warning: assignment makes pointer from integer without a cast
render.c:146: warning: assignment makes pointer from integer without a cast
render.c: In function ‘Nviz_make_current_render_window’:
render.c:204: error: ‘mac_win’ undeclared (first use in this function)
render.c:204: error: (Each undeclared identifier is reported only once
render.c:204: error: for each function it appears in.)
render.c:204: warning: ‘AGLDrawable’ is deprecated
make: *** [OBJ.i386-apple-darwin9.4.0/render.o] Error 1

i.attcorr no longer compiles. Here is the error.

cmb-MBP-2:nviz cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/imagery/i.atcorr
cmb-MBP-2:i.atcorr cmbarton$ make
Makefile:15: warning: overriding commands for target /Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr' ../../include/Make/Module.make:14: warning: ignoring old commands for target /Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/bin/i.atcorr’
c++ -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -arch i386 -Os -g -DPACKAGE="“grassmods”" -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/main.o -c main.cpp
main.cpp: In function ‘void process_raster(int, InputMask, ScaleRange, int, int, int, bool, ScaleRange, bool)’:
main.cpp:309: error: ‘isnan’ was not declared in this scope
make: *** [OBJ.i386-apple-darwin9.4.0/main.o] Error 1

After make install, GRASS will no longer start up in wxPython. It does the startup screen fine, but bombs when it tries to launch the main layer manager. Here is the error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter not initialized (version mismatch?)

Note that I have changed nothing on my system since the last time it compiled and ran fine.

I suspect that an issue that William Kyngesbury recently mentioned may be the cause. vdigit, which compiles now, may do so incorrectly against the system version of Python (2.5.1) rather than the newer one that is my Python default (2.5.2). If so, the version check in the wxGUI startup kills it.

What is the easiest way to diable vdigit to test this?

Michael

Glynn_Clements1 · September 8, 2008, 9:35am

Michael Barton wrote:

3) i.attcorr no longer compiles. Here is the error.

main.cpp:309: error: �isnan� was not declared in this scope
make: *** [OBJ.i386-apple-darwin9.4.0/main.o] Error 1

isnan() isn't part of the C++ standard. It may be provided as an
extension by some versions of gcc, or it may not.

4) After make install, GRASS will no longer start up in wxPython. It
does the startup screen fine, but bombs when it tries to launch the
main layer manager. Here is the error:

GRASS 6.4.svn (Spearfish60_test):~ > Fatal Python error: Interpreter
not initialized (version mismatch?)

Note that I have changed nothing on my system since the last time it
compiled and ran fine.

I suspect that an issue that William Kyngesbury recently mentioned may
be the cause. vdigit, which compiles now, may do so incorrectly
against the system version of Python (2.5.1) rather than the newer one
that is my Python default (2.5.2). If so, the version check in the
wxGUI startup kills it.

What is the easiest way to diable vdigit to test this?

I don't know about the easiest way, but the only robust solution is to
keep nagging the wxGUI developers until they move the high-risk
features (vdigit, nviz) out of the main wxGUI process.

--
Glynn Clements <glynn@gclements.plus.com>

martinl · September 8, 2008, 9:50am

Hi,

2008/9/8 Glynn Clements <glynn@gclements.plus.com>:

I don't know about the easiest way, but the only robust solution is to
keep nagging the wxGUI developers until they move the high-risk
features (vdigit, nviz) out of the main wxGUI process.

it's my plan, I started to elaborate with NvizThread in nviz_mapdisp.py...

M.

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

William_Kyngesburye · September 8, 2008, 1:54pm

disable render.c, not .h.

On Sep 7, 2008, at 11:55 PM, Michael Barton wrote:

Forgot to mention that I tried compiling wxnviz WITH render.h and got the same errors.

Michael

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

Glynn_Clements1 · September 8, 2008, 9:44pm

Martin Landa wrote:

> I don't know about the easiest way, but the only robust solution is to
> keep nagging the wxGUI developers until they move the high-risk
> features (vdigit, nviz) out of the main wxGUI process.

it's my plan, I started to elaborate with NvizThread in nviz_mapdisp.py...

Er, how does that help?

--
Glynn Clements <glynn@gclements.plus.com>

martinl · September 9, 2008, 8:21am

Hi,

2008/9/8 Glynn Clements <glynn@gclements.plus.com>:

> I don't know about the easiest way, but the only robust solution is to
> keep nagging the wxGUI developers until they move the high-risk
> features (vdigit, nviz) out of the main wxGUI process.

it's my plan, I started to elaborate with NvizThread in nviz_mapdisp.py...

Er, how does that help?

For nviz/vdigit extension, there two main points I would like to fix:

* when extension crash (G_fatal_error is called) to avoid crashing whole GUI
* redirect message printed by extension to stdout, strderr to Layer
Manager "Command Area" (goutput.py)

NvizThread class maybe can help in this effort (?)

Thanks for any pointer in advance, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

Glynn_Clements1 · September 10, 2008, 12:07am

Martin Landa wrote:

>> > I don't know about the easiest way, but the only robust solution is to
>> > keep nagging the wxGUI developers until they move the high-risk
>> > features (vdigit, nviz) out of the main wxGUI process.
>>
>> it's my plan, I started to elaborate with NvizThread in nviz_mapdisp.py...
>
> Er, how does that help?

For nviz/vdigit extension, there two main points I would like to fix:

* when extension crash (G_fatal_error is called) to avoid crashing whole GUI
* redirect message printed by extension to stdout, strderr to Layer
Manager "Command Area" (goutput.py)

NvizThread class maybe can help in this effort (?)

Using another thread won't help protect against errors which occur
within C code; for that, you need a completely separate process.
Threads just allow for concurrent execution; they don't provide
isolation.

exit() (as used by G_fatal_error()) terminates the process, not just
the thread. Likewise for fatal signals (e.g. SIGSEGV).

OTOH, A separate thread will help protect against Python exceptions,
which only terminate the thread which raised the exception.

Essentially, vdigit and nviz need to be separate applications. They
can "import" as many wxGUI modules as they want, but any sharing of
data between them and the main wxGUI process will require explicit
communication between the processes.

I'm aware that this results in either reduced usablity or increased
complexity (or some compromise between the two), but it's the only way
to ensure that an error in vdigit/nviz (or rather, in the C code which
they call) only terminates that component rather than the entire GUI.

--
Glynn Clements <glynn@gclements.plus.com>