[GRASS-dev] nviz compile errors on Mac OS X

GRASS GRASS developer
,
1

Just did an update and compile of develbranch_6

../lib/nviz compiles but ../gui/wxpython/nviz does not. Here are the errors.

cmb-MBP-2:g.mremove cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/gui/wxpython/nviz
cmb-MBP-2:nviz cmbarton$ make
c++ -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -g -O2 -fno-common -I/Library/Frameworks/GDAL.framework/Versions/1.5/Headers -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/usr/lib/wx/include/mac-unicode-debug-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -I/usr/X11/include -DPACKAGE=\""grasslibs"\" -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.4.0/include -o OBJ.i386-apple-darwin9.4.0/grass6_wxnviz_wrap.o -c grass6_wxnviz_wrap.cpp
grass6_wxnviz_wrap.cpp:3165: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3173: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3180: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3241: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3781: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp: In static member function ‘static int swig::traits_asptr_stdseq<Seq, T>::asptr(PyObject*, Seq**)’:
grass6_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’ token
grass6_wxnviz_wrap.cpp:3165: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3173: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3180: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3241: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp:3781: error: expected unqualified-id before ‘{’ token
grass6_wxnviz_wrap.cpp: In static member function ‘static int swig::traits_asptr_stdseq<Seq, T>::asptr(PyObject*, Seq**)’:
grass6_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’ token
lipo: can't figure out the architecture type of: /var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//ccMLYkCt.out
make: *** [OBJ.i386-apple-darwin9.4.0/grass6_wxnviz_wrap.o] Error 1

Michael

2

On Sep 13, 2008, at 1:59 PM, Michael Barton wrote:

Just did an update and compile of develbranch_6

../lib/nviz compiles but ../gui/wxpython/nviz does not. Here are the errors.

grass6_wxnviz_wrap.cpp: In static member function ‘static int swig::traits_asptr_stdseq<Seq, T>::asptr(PyObject*, Seq**)’:
grass6_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’ token

I just hit this also in my Mini compile test. Martin - that #undef fix for nviz.i should be:

%module grass6_wxnviz
%{
#include "nviz.h"
#include <grass/gsurf.h>
#include <grass/gstypes.h>
#undef check
%}

ie, inside the braces. Otherwise it doesn't get inserted into the generated wrapper source.

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

3

William,

With these changes, vdigit compiles without errors and wxGUI launches without errors. That's a big plus. Thanks.

vdigit still doesn't work, but at least we can now move forward on that issue.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Sep 13, 2008, at 12:49 PM, William Kyngesburye wrote:

On Sep 13, 2008, at 1:59 PM, Michael Barton wrote:

Just did an update and compile of develbranch_6

../lib/nviz compiles but ../gui/wxpython/nviz does not. Here are the errors.

grass6_wxnviz_wrap.cpp: In static member function ‘static int swig::traits_asptr_stdseq<Seq, T>::asptr(PyObject*, Seq**)’:
grass6_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’ token

I just hit this also in my Mini compile test. Martin - that #undef fix for nviz.i should be:

%module grass6_wxnviz
%{
#include "nviz.h"
#include <grass/gsurf.h>
#include <grass/gstypes.h>
#undef check
%}

ie, inside the braces. Otherwise it doesn't get inserted into the generated wrapper source.

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

4

I just tried this and nviz compiles. Now both vdigit and nviz compile.

But nviz doesn't work yet. It crashes Python when I select it. Any idea how to find out what the error is? Will the report to Apple be useful?

Michael

On Sep 13, 2008, at 12:49 PM, William Kyngesburye wrote:

On Sep 13, 2008, at 1:59 PM, Michael Barton wrote:

Just did an update and compile of develbranch_6

../lib/nviz compiles but ../gui/wxpython/nviz does not. Here are the errors.

grass6_wxnviz_wrap.cpp: In static member function ‘static int swig::traits_asptr_stdseq<Seq, T>::asptr(PyObject*, Seq**)’:
grass6_wxnviz_wrap.cpp:3889: error: expected unqualified-id before ‘?’ token

I just hit this also in my Mini compile test. Martin - that #undef fix for nviz.i should be:

%module grass6_wxnviz
%{
#include "nviz.h"
#include <grass/gsurf.h>
#include <grass/gstypes.h>
#undef check
%}

ie, inside the braces. Otherwise it doesn't get inserted into the generated wrapper source.

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

5

On Sep 13, 2008, at 8:07 PM, Michael Barton wrote:

I just tried this and nviz compiles. Now both vdigit and nviz compile.

But nviz doesn't work yet. It crashes Python when I select it. Any idea how to find out what the error is? Will the report to Apple be useful?

Probably not. But this crashlog that it generates is wxactly what you need to find the error.

It will have something about a thread crashing and the call trace. Or maybe just an error about a missing library or symbol.

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

6

Attached is the crashlog

There is something a bit odd with the header information. It has the right path for my MacPython version installation, but the version is for the Apple system Python. I wonder if this is along the same lines as the issue that was killing vdigit.

Michael

(attachments)

Python_2008-09-13-224821_cmb-MBP-2.crash (46.6 KB)

7

Michael Barton wrote:

Attached is the crashlog

There is something a bit odd with the header information. It has the
right path for my MacPython version installation, but the version is
for the Apple system Python. I wonder if this is along the same lines
as the issue that was killing vdigit.

If it's mixing binaries for different Python versions, that isn't
going to work.

Certainly, the crash dump is consistent with that scenario, i.e.
crashing while dlopen()ing a shared library.

Remind me again: why can't you use the system Python? Is wxPython not
available for the system Python?

Binary Images:
0x13fe7000 - 0x13fe7ff1 +libXau.6.dylib ??? (???) <af0fefbbf38efd4df94bedea64d5019d> /usr/X11/lib/libXau.6.dylib

0x14758000 - 0x1475dffc +libSM.6.dylib ??? (???) <da2933333b791701efb3878166c35435> /usr/X11/lib/libSM.6.dylib
0x147e6000 - 0x147f7ff7 +libICE.6.dylib ??? (???) <68bd0c63da68b6c30273693c7b775c4f> /usr/X11/lib/libICE.6.dylib

0x16012000 - 0x1605dff8 +libXt.6.dylib ??? (???) <09f2a2bdce4a8d5c4b753254435c52ea> /usr/X11/lib/libXt.6.dylib
0x16072000 - 0x1615dfe7 +libX11.6.dylib ??? (???) <b17988a7d0432be8daf271882b9f1d45> /usr/X11/lib/libX11.6.dylib

0x17442000 - 0x17444fef +libXdmcp.6.dylib ??? (???) <a12913daa7d2b4efb341cb698f4182fa> /usr/X11/lib/libXdmcp.6.dylib

What are those doing in there?

More importantly:

0x1de6000 - 0x2483607 +libwx_macud-2.8.0.dylib ??? (???) /usr/local/lib/wxPython-unicode-2.8.8.1/lib/libwx_macud-2.8.0.dylib
0x1586c000 - 0x15d39fff libwx_macud-2.8.0.dylib ??? (???) <cfd5a59e5c9ce50c5a7a8888acfbd15d> /usr/lib/libwx_macud-2.8.0.dylib

Is it actually loading two different libwx_macud-2.8.0.dylib
libraries? That certainly doesn't look good.

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

8

On Sep 14, 2008, at 12:52 AM, Michael Barton wrote:

Attached is the crashlog

There is something a bit odd with the header information. It has the right path for my MacPython version installation, but the version is for the Apple system Python. I wonder if this is along the same lines as the issue that was killing vdigit.

Michael

For some reason the MacPython has always been built with that 2.5a0 version number, no matter what 2.5.x version it really is. So everything there is macpython.

It looks like it's crashing trying to load a module, but it's not saying what it is.

*Update*

Test on Mini: nviz sortof runs (no crash) - the "Please wait, loading data" window just sits there and the display remains 2D, but there are a palette and quit (nviz) tool buttons. I can "quit" nviz and the please wait dialog goes away.

In addition to the other macpython + wx I mentioned, I installed PyOpenGl 3.0.0b5.

I get the same when I compile for the system python.

How did you configure GRASS? The relevant options I used are:

  --with-x
  --with-python
  --with-opengl=aqua
  --without-tcltk
  --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

I didn't use a path for python (not needed).

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

9

On Sep 14, 2008, at 3:49 AM, Glynn Clements wrote:

Remind me again: why can't you use the system Python? Is wxPython not
available for the system Python?

It's just a user preference. Some prefer to have the most recent python and wxpython and other modules. The system python fits the minimum requirements for GRASS (so far).

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

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

10

On Sep 14, 2008, at 1:49 AM, Glynn Clements wrote:

Michael Barton wrote:

Attached is the crashlog

There is something a bit odd with the header information. It has the
right path for my MacPython version installation, but the version is
for the Apple system Python. I wonder if this is along the same lines
as the issue that was killing vdigit.

If it's mixing binaries for different Python versions, that isn't
going to work.

Certainly, the crash dump is consistent with that scenario, i.e.
crashing while dlopen()ing a shared library.

Remind me again: why can't you use the system Python? Is wxPython not
available for the system Python?

The system Python is 2.5.0 alpha. I was already using 2.5.1 before I upgraded to OS X 10.5 with the alpha version of 2.5.0 because prior to 10.5, Apple shipped only 2.3 with its OS. I don't know why. One of the mysteries of Cupertino.

Binary Images:
0x13fe7000 - 0x13fe7ff1 +libXau.6.dylib ??? (???) <af0fefbbf38efd4df94bedea64d5019d> /usr/X11/lib/libXau.6.dylib

0x14758000 - 0x1475dffc +libSM.6.dylib ??? (???) <da2933333b791701efb3878166c35435> /usr/X11/lib/libSM.6.dylib
0x147e6000 - 0x147f7ff7 +libICE.6.dylib ??? (???) <68bd0c63da68b6c30273693c7b775c4f> /usr/X11/lib/libICE.6.dylib

0x16012000 - 0x1605dff8 +libXt.6.dylib ??? (???) <09f2a2bdce4a8d5c4b753254435c52ea> /usr/X11/lib/libXt.6.dylib
0x16072000 - 0x1615dfe7 +libX11.6.dylib ??? (???) <b17988a7d0432be8daf271882b9f1d45> /usr/X11/lib/libX11.6.dylib

0x17442000 - 0x17444fef +libXdmcp.6.dylib ??? (???) <a12913daa7d2b4efb341cb698f4182fa> /usr/X11/lib/libXdmcp.6.dylib

What are those doing in there?

There should be no x11 calls. Is this something hard coded for Linux somewhere?

More importantly:

0x1de6000 - 0x2483607 +libwx_macud-2.8.0.dylib ??? (???) /usr/local/lib/wxPython-unicode-2.8.8.1/lib/libwx_macud-2.8.0.dylib

The date on these libraries seem to be associate them with the system Python install

0x1586c000 - 0x15d39fff libwx_macud-2.8.0.dylib ??? (???) <cfd5a59e5c9ce50c5a7a8888acfbd15d> /usr/lib/libwx_macud-2.8.0.dylib

These are associated with the installation of the current wxPython 2.8.8

Is it actually loading two different libwx_macud-2.8.0.dylib
libraries? That certainly doesn't look good.

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

11

On Sep 14, 2008, at 11:42 AM, Michael Barton wrote:

The system Python is 2.5.0 alpha. I was already using 2.5.1 before I upgraded to OS X 10.5 with the alpha version of 2.5.0 because prior to 10.5, Apple shipped only 2.3 with its OS. I don't know why. One of the mysteries of Cupertino.

That's a little backwards. The crashlog shows the "framework" version, as you find in the framework's info.plist (or language infoplist.strings, or version.plist), or what you get with Get Info. You will see the real version when you start Python in a Terminal.

The Leopard system python is 2.5.1. The "framework" version is reported as 2.5.

MacPython always reports it's "framework" version as 2.5a0. But it's current actual version is 2.5.2.

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

12

William,

see below

On Sep 14, 2008, at 9:07 AM, William Kyngesburye wrote:

On Sep 14, 2008, at 12:52 AM, Michael Barton wrote:

Attached is the crashlog

There is something a bit odd with the header information. It has the right path for my MacPython version installation, but the version is for the Apple system Python. I wonder if this is along the same lines as the issue that was killing vdigit.

Michael

For some reason the MacPython has always been built with that 2.5a0 version number, no matter what 2.5.x version it really is. So everything there is macpython.

That explains my confusion over this.

It looks like it's crashing trying to load a module, but it's not saying what it is.

*Update*

Test on Mini: nviz sortof runs (no crash) - the "Please wait, loading data" window just sits there and the display remains 2D, but there are a palette and quit (nviz) tool buttons. I can "quit" nviz and the please wait dialog goes away.

In addition to the other macpython + wx I mentioned, I installed PyOpenGl 3.0.0b5.

This shouldn't be necessary to run OpenGL but maybe Martin is using it for something.

I get the same when I compile for the system python.

How did you configure GRASS? The relevant options I used are:

--with-x
--with-python
--with-opengl=aqua
--without-tcltk
--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

Here is a potential problem. I was using

--with-x
--with-opengl=aqua
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders"
--with-python=/usr/local/bin/python-config
--with-wxwidgets=/usr/bin/wx-config (on someone's suggestion recently to solve a different issue)

I just changed that and compiled using

  --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

But I'm still getting the python crash. I'm attaching the new crash log.

If OSX 10.5 is installing Python 2.5.1, maybe I should ditch Python 2.5.2 for simplicity's sake. I still want the most recent wxPython however, because it contains some important bug fixes for OSX. Do you think I can just uninstall Python 2.5.2 and wxPython, then reinstall wxPython linked to the system Python? Can I just move other site packages or do I have to reinstall everything?

Michael

(attachments)

Python_2008-09-14-100112_cmb-MBP-2.crash (46.3 KB)

13

I went ahead and installed PyOpenGL, recompiled ../lib/nviz and ../wxpython/nviz.

Same result. I'm glad that you're getting partway there on the Mini, but not sure what else I need to do to duplicate your setup. I'm including my compile ritual below for comparison. Note, I AM building the TclTk GUI too, but that shouldn't matter.

Michael

export CFLAGS="-arch i386 -Os -g"
export LDFLAGS="-arch i386 -Os -g"

export NAD2BIN=/Library/Frameworks/PROJ.framework/Programs/nad2bin

./configure --with-freetype --with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/include/freetype2 /Library/Frameworks/FreeType.framework/unix/include" --with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj --with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/include --with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib --without-postgres --without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/include --with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-x --with-cxx --with-opengl=aqua --without-readline --prefix=/Applications/GRASS --enable-macosx-app --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config --with-wxwidgets=/usr/bin/wx-config --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders"

after configure, *before* make, edit include/make/platform.make:
TCLTKLIBS = -framework Tcl -framework Tk

____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Sep 14, 2008, at 9:07 AM, William Kyngesburye wrote:

On Sep 14, 2008, at 12:52 AM, Michael Barton wrote:

Attached is the crashlog

There is something a bit odd with the header information. It has the right path for my MacPython version installation, but the version is for the Apple system Python. I wonder if this is along the same lines as the issue that was killing vdigit.

Michael

For some reason the MacPython has always been built with that 2.5a0 version number, no matter what 2.5.x version it really is. So everything there is macpython.

It looks like it's crashing trying to load a module, but it's not saying what it is.

*Update*

Test on Mini: nviz sortof runs (no crash) - the "Please wait, loading data" window just sits there and the display remains 2D, but there are a palette and quit (nviz) tool buttons. I can "quit" nviz and the please wait dialog goes away.

In addition to the other macpython + wx I mentioned, I installed PyOpenGl 3.0.0b5.

I get the same when I compile for the system python.

How did you configure GRASS? The relevant options I used are:

--with-x
--with-python
--with-opengl=aqua
--without-tcltk
--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

I didn't use a path for python (not needed).

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

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

14

On Sep 14, 2008, at 12:50 PM, Michael Barton wrote:

Test on Mini: nviz sortof runs (no crash) - the "Please wait, loading data" window just sits there and the display remains 2D, but there are a palette and quit (nviz) tool buttons. I can "quit" nviz and the please wait dialog goes away.

In addition to the other macpython + wx I mentioned, I installed PyOpenGl 3.0.0b5.

This shouldn't be necessary to run OpenGL but maybe Martin is using it for something.

nviz wouldn't run without it.

How did you configure GRASS? The relevant options I used are:

--with-x
--with-python
--with-opengl=aqua
--without-tcltk
--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

Here is a potential problem. I was using

--with-x
--with-opengl=aqua
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders"
--with-python=/usr/local/bin/python-config
--with-wxwidgets=/usr/bin/wx-config (on someone's suggestion recently to solve a different issue)

I just changed that and compiled using

--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config

Ah, you were mixing the python.org python with the system's wxpython. The wx binary extensions in GRASS (the nviz and vdigit .so's) were linked to the system wxwidgets libraries, but then the GUI loaded your wxpython 2.8.8.1, thus some binary confusion.

But I'm still getting the python crash. I'm attaching the new crash log.

Looks pretty much the same - it's trying to load a binary module, but it doesn't say what it is.

There are no system wx libraries now, which is good.

Just to test, try configuring without tcltk. As Glynn pointed out, something is loading the X11 libraries, which are completely unnecessary within the Python GUI. All those do is enable the tcltk nviz, and have nothing to do with the tcltk GUI anyways (if you want to keep that option open). Even tho you configure with the aqua tcltk, maybe that's still getting some X11 into the mix.

with-x isn't causing me any problems, but if disabling tcltk doesn't help, try disabling X.

Of course, this may have nothing to do with nviz crashing, but it's worth a try.

If OSX 10.5 is installing Python 2.5.1, maybe I should ditch Python 2.5.2 for simplicity's sake. I still want the most recent wxPython however, because it contains some important bug fixes for OSX. Do you think I can just uninstall Python 2.5.2 and wxPython, then reinstall wxPython linked to the system Python? Can I just move other site packages or do I have to reinstall everything?

Either Python should be fine. I don't see a reason to stop using macpython if you want a more recent wxpython.

Reinstalling a recent wxpython for the system python would take compiling wxpython from scratch - the binary extension bits are linked to the macpython. I've considered trying it out someday for kicks (and installing an updated numpy for the system python) - it should work.

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

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

15

On Sep 14, 2008, at 1:22 PM, Michael Barton wrote:

I went ahead and installed PyOpenGL, recompiled ../lib/nviz and ../wxpython/nviz.

Nothing binary in PyOpenGL, so no need to recompile.

Same result. I'm glad that you're getting partway there on the Mini, but not sure what else I need to do to duplicate your setup. I'm including my compile ritual below for comparison. Note, I AM building the TclTk GUI too, but that shouldn't matter.

Michael

export CFLAGS="-arch i386 -Os -g"
export LDFLAGS="-arch i386 -Os -g"

If below doesn't help, try without the -g flag?

--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config --with-wxwidgets=/usr/bin/wx-config

Um, you should only use the /usr/local one. I'm guessing that the 2nd --with-wxwidgets completely overrides the first.

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

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

16

Curses. A typo.

Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On Sep 14, 2008, at 11:36 AM, William Kyngesburye wrote:

--with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.8.1/bin/wx-config --with-wxwidgets=/usr/bin/wx-config

Um, you should only use the /usr/local one. I'm guessing that the 2nd --with-wxwidgets completely overrides the first.

17

Typo fixed.

Recompiled (did make distclean between each compilation just to make sure that nothing lurking in a previous build could cause a problem) using: --without-x --without-tcltk AND --with-x --without-tcltk

Still no go. I'm attaching crash logs. I am also noticing that every make and make install causes a r.terraflow crash--even though I've not launched r.terraflow. I'm not sure what this is about, but note that the problematic wxPython modules and r.terraflow all use C++.

I'm attaching the r.terraflow crash log too, in case it holds a clue.

Michael

(attachments)

Python_without-x_without-tcltk.crash (46.7 KB)
Python_with-x_without-tcltk.crash (46.7 KB)
r.terraflow_2008-09-14-121541_cmb-MBP-2.crash (18.6 KB)

18

I tried it without debug and still got the same kind of crash. Attached is the latest crash log: --with-x --without-tcltk and without the -g flags.

Michael

(attachments)

Python_2008-09-14-125829_cmb-MBP-2.crash (46.7 KB)

19

On Sep 14, 2008, at 2:22 PM, Michael Barton wrote:

Typo fixed.

Recompiled (did make distclean between each compilation just to make sure that nothing lurking in a previous build could cause a problem) using: --without-x --without-tcltk AND --with-x --without-tcltk

Still no go. I'm attaching crash logs. I am also noticing that every make and make install causes a r.terraflow crash--even though I've not launched r.terraflow. I'm not sure what this is about, but note that the problematic wxPython modules and r.terraflow all use C++.

I'm attaching the r.terraflow crash log too, in case it holds a clue.

I get those also. It hasn't bothered me enough yet to look into it.

Michael

<Python_without-x_without-tcltk.crash>

<Python_with-x_without-tcltk.crash>

<r.terraflow_2008-09-14-121541_cmb-MBP-2.crash>

Still some X11 libs in there, so it's probably something else outside GRASS loading them (something in python or wx?). Dead end.

Though I do see that the wxnviz makefile unconditionally links the X11 libraries. Maybe something else to move to the non-OSX EXTRA_LIBS - since OSX will always be using an Aqua python (I suppose it's theoretically possibly to compile GRASS on OSX with all X11-based python and wxpython) - or conditionalize on the OpenGL flag (whether it's aqua or X11 or Windows).

On further inspection of the crashlog, I think it's the _grass6_wxnviz.so that it's choking on (makes sense). I see that libgrass_nviz is loaded in the binary images section, but not _grass6_wxnviz.so (_grass6_wxnviz.so and nviz2 are the only things that link libgrass_nviz). So it was in the middle of loading it and got libgrass_nviz loaded, then crash. From there I'm at a loss.

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

All generalizations are dangerous, even this one.

20

On Sep 14, 2008, at 1:02 PM, William Kyngesburye wrote:

On Sep 14, 2008, at 2:22 PM, Michael Barton wrote:

Typo fixed.

Recompiled (did make distclean between each compilation just to make sure that nothing lurking in a previous build could cause a problem) using: --without-x --without-tcltk AND --with-x --without-tcltk

Still no go. I'm attaching crash logs. I am also noticing that every make and make install causes a r.terraflow crash--even though I've not launched r.terraflow. I'm not sure what this is about, but note that the problematic wxPython modules and r.terraflow all use C++.

I'm attaching the r.terraflow crash log too, in case it holds a clue.

I get those also. It hasn't bothered me enough yet to look into it.

Michael

<Python_without-x_without-tcltk.crash>

<Python_with-x_without-tcltk.crash>

<r.terraflow_2008-09-14-121541_cmb-MBP-2.crash>

Still some X11 libs in there, so it's probably something else outside GRASS loading them (something in python or wx?). Dead end.

Though I do see that the wxnviz makefile unconditionally links the X11 libraries. Maybe something else to move to the non-OSX EXTRA_LIBS - since OSX will always be using an Aqua python (I suppose it's theoretically possibly to compile GRASS on OSX with all X11-based python and wxpython) - or conditionalize on the OpenGL flag (whether it's aqua or X11 or Windows).

On further inspection of the crashlog, I think it's the _grass6_wxnviz.so that it's choking on (makes sense). I see that libgrass_nviz is loaded in the binary images section, but not _grass6_wxnviz.so (_grass6_wxnviz.so and nviz2 are the only things that link libgrass_nviz). So it was in the middle of loading it and got libgrass_nviz loaded, then crash. From there I'm at a loss.

That's the file created with swig. Same kind of file that vdigit has been choking on.

Michael

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

All generalizations are dangerous, even this one.