[GRASS-dev] compilation success

cmbarton · October 8, 2008, 9:40pm

I just updated GRASS 6.4 from the SVN and compiled. I had to compile the wxPython nviz and vdigit manually, but all compiled. This is very good news. The bad news is that neither vdigit nor nviz yet work.

When I try vdigit, I still get a "Unable to initialize display driver" error.

When I try the new nviz, I nothing happens visually, but I get the following in the layer manager output window.

Traceback (most recent call last):
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/toolbars.py", line 250, in
OnSelectTool

self.mapdisplay.AddToolbar("nviz")
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/mapdisp.py", line 2701, in AddToolbar

import nviz
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz.py", line 49, in <module>

import nviz_mapdisp
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_mapdisp.py", line 40, in <module>

import grass6_wxnviz as wxnviz
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/nviz/grass6_wxnviz.py", line 7, in <module>

import _grass6_wxnviz
ImportError
:
dynamic module does not define init function
(init_grass6_wxnviz)

===================

I have removed MacPython and am using the Python 2.5.2 that comes with my Mac. I installed wxPython 2.8.9.1 and it works fine with the native Python.

Michael

Glynn_Clements1 · October 8, 2008, 11:05pm

Michael Barton wrote:

When I try the new nviz, I nothing happens visually, but I get the
following in the layer manager output window.

import grass6_wxnviz as wxnviz
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/nviz/grass6_wxnviz.py", line 7, in <module>

import _grass6_wxnviz
ImportError
:
dynamic module does not define init function
(init_grass6_wxnviz)

Is gui/wxpython/nviz/grass6_wxnviz_wrap.cpp generated correctly?

It should contain the line:

#define SWIG_init init_grass6_wxnviz

and then the function:

SWIGEXPORT void SWIG_init(void) {

at the bottom of the file.

Are there any errors or warnings from compilation in gui/wxpython/nviz?

Does init_grass6_wxnviz (or anything similar) show up in the output
from:

nm -D OBJ.*/_grass6_wxnviz.so
?

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

William_Kyngesburye · October 9, 2008, 3:46am

I updated wxpython/nviz/nviz.i - the #undef check fix from a while back was wrong, so it wouldn't compile. I haven't tried running it yet, I only have my brain half on this right now.

But I ran into another interesting compile issue, that probably only a few would run into, when compiling a universal binary. Using the system python and an up-to-date wxpython, the ppc side is missing some symbols in the wx libraries. Looks like a problem with the wxpython builds, but not the system wxpython. This was with wxpython 2.8.9.1 and 2.8.7.1 (and probably 2.8.8.1 also).

I tried a single-arch ppc-only (from intel), and that didn't work either. I don't have a PPC Leopard Mac to try a native PPC build.

c++ -o OBJ.i386-apple-darwin9.5.0/_grass6_wxnviz.so ......

Undefined symbols:
   "typeinfo for wxThread", referenced from:
       typeinfo for wxThreadHelperThreadin change_view.o
       typeinfo for wxThreadHelperThreadin draw.o
       typeinfo for wxThreadHelperThreadin init.o
       typeinfo for wxThreadHelperThreadin lights.o
       typeinfo for wxThreadHelperThreadin load.o
       typeinfo for wxThreadHelperThreadin surface.o
       typeinfo for wxThreadHelperThreadin vector.o
       typeinfo for wxThreadHelperThreadin volume.o
       typeinfo for wxThreadHelperThreadin grass6_wxnviz_wrap.o
ld: symbol(s) not found

Indeed, on the Intel side of libwx_macud wxThreadHelperThread exists, but it does not on the PPC side.

And strangely, there are no wx link errors in vdigit. Hmmm...

Now I come back to another patch I suggested a while back - the Python library/framework should not be directly linked on OSX. So, in the wx nviz and vdigit makefiles, the inclusion of $(PYTHONLDFLAGS) needs to be conditionalized like -lgdi is for nviz. --> When I do this, the wxThreadHelperThread error above goes away.

I applied this to SVN.

On Oct 8, 2008, at 4:40 PM, Michael Barton wrote:

I just updated GRASS 6.4 from the SVN and compiled. I had to compile the wxPython nviz and vdigit manually, but all compiled. This is very good news. The bad news is that neither vdigit nor nviz yet work.

When I try vdigit, I still get a "Unable to initialize display driver" error.

When I try the new nviz, I nothing happens visually, but I get the following in the layer manager output window.

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

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

cmbarton · October 9, 2008, 4:26am

I'll try again. One of my students compiled GRASS 6.4 today on a PPC OSX 10.5 machine. It seemed to go well using native Python and new wxPython. Oddly (but fortunately) nviz (the old TclTk one) DOES seem to work fine with that. I'm not sure what is going on with mine.

Are you compiling aqua or x11 TclTk?

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 Oct 8, 2008, at 8:46 PM, William Kyngesburye wrote:

I updated wxpython/nviz/nviz.i - the #undef check fix from a while back was wrong, so it wouldn't compile. I haven't tried running it yet, I only have my brain half on this right now.

But I ran into another interesting compile issue, that probably only a few would run into, when compiling a universal binary. Using the system python and an up-to-date wxpython, the ppc side is missing some symbols in the wx libraries. Looks like a problem with the wxpython builds, but not the system wxpython. This was with wxpython 2.8.9.1 and 2.8.7.1 (and probably 2.8.8.1 also).

I tried a single-arch ppc-only (from intel), and that didn't work either. I don't have a PPC Leopard Mac to try a native PPC build.

c++ -o OBJ.i386-apple-darwin9.5.0/_grass6_wxnviz.so ......

Undefined symbols:
"typeinfo for wxThread", referenced from:
     typeinfo for wxThreadHelperThreadin change_view.o
     typeinfo for wxThreadHelperThreadin draw.o
     typeinfo for wxThreadHelperThreadin init.o
     typeinfo for wxThreadHelperThreadin lights.o
     typeinfo for wxThreadHelperThreadin load.o
     typeinfo for wxThreadHelperThreadin surface.o
     typeinfo for wxThreadHelperThreadin vector.o
     typeinfo for wxThreadHelperThreadin volume.o
     typeinfo for wxThreadHelperThreadin grass6_wxnviz_wrap.o
ld: symbol(s) not found

Indeed, on the Intel side of libwx_macud wxThreadHelperThread exists, but it does not on the PPC side.

And strangely, there are no wx link errors in vdigit. Hmmm...

Now I come back to another patch I suggested a while back - the Python library/framework should not be directly linked on OSX. So, in the wx nviz and vdigit makefiles, the inclusion of $(PYTHONLDFLAGS) needs to be conditionalized like -lgdi is for nviz. --> When I do this, the wxThreadHelperThread error above goes away.

I applied this to SVN.

On Oct 8, 2008, at 4:40 PM, Michael Barton wrote:

I just updated GRASS 6.4 from the SVN and compiled. I had to compile the wxPython nviz and vdigit manually, but all compiled. This is very good news. The bad news is that neither vdigit nor nviz yet work.

When I try vdigit, I still get a "Unable to initialize display driver" error.

When I try the new nviz, I nothing happens visually, but I get the following in the layer manager output window.

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

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

cmbarton · October 9, 2008, 4:37am

On Oct 8, 2008, at 4:05 PM, Glynn Clements wrote:

Michael Barton wrote:

When I try the new nviz, I nothing happens visually, but I get the
following in the layer manager output window.

import grass6_wxnviz as wxnviz
  File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/nviz/grass6_wxnviz.py", line 7, in <module>

import _grass6_wxnviz
ImportError
:
dynamic module does not define init function
(init_grass6_wxnviz)

Is gui/wxpython/nviz/grass6_wxnviz_wrap.cpp generated correctly?

It should contain the line:

  #define SWIG_init init_grass6_wxnviz

and then the function:

  SWIGEXPORT void SWIG_init(void) {

at the bottom of the file.

This looks correct. These lines/functions are present.

Are there any errors or warnings from compilation in gui/wxpython/nviz?

As before, I had to remove render.c and the command line version will not compile. Otherwise no errors.

Does init_grass6_wxnviz (or anything similar) show up in the output
from:

nm -D OBJ.*/_grass6_wxnviz.so
?

I'm not sure I understand what you're asking. But here is a result.

cmb-MBP-2:~ cmbarton$ cd /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc/wxpython/nviz
cmb-MBP-2:nviz cmbarton$ nm -D OBJ.*/_grass6_wxnviz.so
nm: invalid argument -D
Usage: nm [-agnoprumxjlfAP[s segname sectname] [-] [-t format] [[-arch <arch_flag>] ...] [file ...]

Michael

cmbarton · October 9, 2008, 5:35am

With William's recent fix, I got farther tonight on getting a working wxPython nviz than ever before.

I still have to remove render.c, but otherwise compilation goes well. When I select nviz from the map display, I now get a message box saying "Please wait, loading data..." and I get a partial nviz toolbar (color picker and exit door). Then it sits. In the layer manager output window, I get the following error.

===============
Traceback (most recent call last):
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/toolbars.py", line 250, in
OnSelectTool

self.mapdisplay.AddToolbar("nviz")
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/mapdisp.py", line 2758, in AddToolbar

mapWindow=self.MapWindow3D)
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 69, in __init__

self.__createViewPage()
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 158, in
__createViewPage

bind=(self.OnViewChange, self.OnViewChanged,
self.OnViewChangedSpin))
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 1308, in
CreateControl

size=sizeW)
File "/BinaryCache/wxWidgets/wxWidgets-11~57/Root/System/L
ibrary/Frameworks/Python.framework/Versions/2.5/Extras/lib/p
ython/wx-2.8-mac-unicode/wx/_controls.py", line 2600, in
__init__
wx._core
.
PyAssertionError
:
C++ assertion "!(style & wxSL_VERTICAL) || !(style &
wxSL_HORIZONTAL)" failed at ../src/mac/carbon/slider.cpp(98)
in Create(): incompatible slider direction and orientation

===============

Looks like it may be stuck on a bad wxPython widget definition.

Michael

On Oct 8, 2008, at 4:05 PM, Glynn Clements wrote:

Michael Barton wrote:

When I try the new nviz, I nothing happens visually, but I get the
following in the layer manager output window.

import grass6_wxnviz as wxnviz
  File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/nviz/grass6_wxnviz.py", line 7, in <module>

import _grass6_wxnviz
ImportError
:
dynamic module does not define init function
(init_grass6_wxnviz)

Is gui/wxpython/nviz/grass6_wxnviz_wrap.cpp generated correctly?

It should contain the line:

  #define SWIG_init init_grass6_wxnviz

and then the function:

  SWIGEXPORT void SWIG_init(void) {

at the bottom of the file.

Are there any errors or warnings from compilation in gui/wxpython/nviz?

Does init_grass6_wxnviz (or anything similar) show up in the output
from:

  nm -D OBJ.*/_grass6_wxnviz.so
?

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

Glynn_Clements1 · October 9, 2008, 9:27am

Michael Barton wrote:

> Does init_grass6_wxnviz (or anything similar) show up in the output
> from:
>
> nm -D OBJ.*/_grass6_wxnviz.so
> ?

I'm not sure I understand what you're asking. But here is a result.

cmb-MBP-2:~ cmbarton$ cd /Applications/Grass/GRASS-6.4.app/Contents/
MacOS/etc/wxpython/nviz
cmb-MBP-2:nviz cmbarton$ nm -D OBJ.*/_grass6_wxnviz.so
nm: invalid argument -D
Usage: nm [-agnoprumxjlfAP[s segname sectname] [-] [-t format] [[-arch
<arch_flag>] ...] [file ...]

Okay; try it without -D. Also try it on OBJ.*/grass7_wxnviz_wrap.o.

To be honest, I'm not particularly confident of the OSX-specific rule
for building the module:

  ifeq ($(findstring darwin,$(ARCH)),darwin)
    $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS)
  else

I would expect that command to try to build an executable.

What does "file" say about the resulting .so file? Is it comparable to
the result of any of the binary modules which are part of the standard
Python distribution?

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

Glynn_Clements1 · October 9, 2008, 9:38am

Michael Barton wrote:

With William's recent fix, I got farther tonight on getting a working
wxPython nviz than ever before.

I still have to remove render.c, but otherwise compilation goes well.
When I select nviz from the map display, I now get a message box
saying "Please wait, loading data..." and I get a partial nviz toolbar
(color picker and exit door). Then it sits. In the layer manager
output window, I get the following error.
File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 1308, in
CreateControl

size=sizeW)

C++ assertion "!(style & wxSL_VERTICAL) || !(style &
wxSL_HORIZONTAL)" failed at ../src/mac/carbon/slider.cpp(98)
in Create(): incompatible slider direction and orientation

The style parameter is set thus:

        if sliderHor:
            style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \
                wx.SL_BOTTOM
            sizeW = (size, -1)
        else:
            style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \
                wx.SL_BOTTOM | wx.SL_INVERSE
            sizeW = (-1, size)

Although it doesn't explicitly say so in the documentation, I believe
that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL.

AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT.

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

William_Kyngesburye · October 9, 2008, 1:44pm

On Oct 9, 2008, at 4:38 AM, Glynn Clements wrote:

Michael Barton wrote:

With William's recent fix, I got farther tonight on getting a working
wxPython nviz than ever before.

I still have to remove render.c, but otherwise compilation goes well.
When I select nviz from the map display, I now get a message box
saying "Please wait, loading data..." and I get a partial nviz toolbar
(color picker and exit door). Then it sits. In the layer manager
output window, I get the following error.
  File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 1308, in
CreateControl

size=sizeW)

C++ assertion "!(style & wxSL_VERTICAL) || !(style &
wxSL_HORIZONTAL)" failed at ../src/mac/carbon/slider.cpp(98)
in Create(): incompatible slider direction and orientation

The style parameter is set thus:

       if sliderHor:
           style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \
               wx.SL_BOTTOM
           sizeW = (size, -1)
       else:
           style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \
               wx.SL_BOTTOM | wx.SL_INVERSE
           sizeW = (-1, size)

Although it doesn't explicitly say so in the documentation, I believe
that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL.

AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT.

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

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

Earth: "Mostly harmless"

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

William_Kyngesburye · October 9, 2008, 1:48pm

On Oct 9, 2008, at 4:27 AM, Glynn Clements wrote:

To be honest, I'm not particularly confident of the OSX-specific rule
for building the module:

  ifeq ($(findstring darwin,$(ARCH)),darwin)
    $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS)
  else

I would expect that command to try to build an executable.

This works because there is also a conditional on setting EXTRA_LIBS, so that it will build a module (-bundle), which is a little different than a library on OSX. We don't want SHLIB_LD because it has the -dynamiclib flag hardwired into it.

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

The equator is so long, it could encircle the earth completely once.

William_Kyngesburye · October 9, 2008, 1:54pm

On Oct 9, 2008, at 8:48 AM, William Kyngesburye wrote:

On Oct 9, 2008, at 4:27 AM, Glynn Clements wrote:

To be honest, I'm not particularly confident of the OSX-specific rule
for building the module:

  ifeq ($(findstring darwin,$(ARCH)),darwin)
    $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS)
  else

I would expect that command to try to build an executable.

This works because there is also a conditional on setting EXTRA_LIBS, so that it will build a module (-bundle), which is a little different than a library on OSX. We don't want SHLIB_LD because it has the -dynamiclib flag hardwired into it.

Ah, but until yesterday, this EXTRA_LIBS conditional was only in the vdigit makefile (because it was needed for the -lgdi bit). So I guess I fixed two problems without realizing it

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

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

cmbarton · October 9, 2008, 2:54pm

On Oct 9, 2008, at 2:38 AM, Glynn Clements wrote:

Michael Barton wrote:

With William's recent fix, I got farther tonight on getting a working
wxPython nviz than ever before.

I still have to remove render.c, but otherwise compilation goes well.
When I select nviz from the map display, I now get a message box
saying "Please wait, loading data..." and I get a partial nviz toolbar
(color picker and exit door). Then it sits. In the layer manager
output window, I get the following error.
  File "/Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc
/wxpython/gui_modules/nviz_tools.py", line 1308, in
CreateControl

size=sizeW)

C++ assertion "!(style & wxSL_VERTICAL) || !(style &
wxSL_HORIZONTAL)" failed at ../src/mac/carbon/slider.cpp(98)
in Create(): incompatible slider direction and orientation

The style parameter is set thus:

       if sliderHor:
           style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \
               wx.SL_BOTTOM
           sizeW = (size, -1)
       else:
           style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \
               wx.SL_BOTTOM | wx.SL_INVERSE
           sizeW = (-1, size)

Although it doesn't explicitly say so in the documentation, I believe
that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL.

AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT.

I just deleted the wx.SL_BOTTOM style and nviz works on the Mac!!!

Really cool!

I committed to develbranch_6. Could someone else test to make sure that this doesn't cause a problem somewhere else? I have to head to class.

Thanks for the guidance on this, and the efforts of all of you working together.

Cheers
Michael

Glynn_Clements1 · October 10, 2008, 2:36am

William Kyngesburye wrote:

> To be honest, I'm not particularly confident of the OSX-specific rule
> for building the module:
>
> ifeq ($(findstring darwin,$(ARCH)),darwin)
> $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS)
> else
>
> I would expect that command to try to build an executable.

This works because there is also a conditional on setting EXTRA_LIBS,

Where?

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

William_Kyngesburye · October 10, 2008, 2:08pm

On Oct 9, 2008, at 9:36 PM, Glynn Clements wrote:

William Kyngesburye wrote:

To be honest, I'm not particularly confident of the OSX-specific rule
for building the module:

  ifeq ($(findstring darwin,$(ARCH)),darwin)
    $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS)
  else

I would expect that command to try to build an executable.

This works because there is also a conditional on setting EXTRA_LIBS,

Where?

It was already in the vdigit makefile (coincidentally, for libgdi handling), and I added it to the nviz makefile when I moved PYTHONLDFLAGS:

http://trac.osgeo.org/grass/changeset/33771

This is in dev6 branch right now. I didn't mirror it to trunk (yet).

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

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

William_Kyngesburye · October 14, 2008, 4:05pm

On Oct 9, 2008, at 9:54 AM, Michael Barton wrote:

I just deleted the wx.SL_BOTTOM style and nviz works on the Mac!!!

Really cool!

I committed to develbranch_6. Could someone else test to make sure that this doesn't cause a problem somewhere else? I have to head to class.

Thanks for the guidance on this, and the efforts of all of you working together.

I just had a chance to try wx nviz. Woohoo!

A couple notes:

- (not really nviz) The display window titlebar starts under the OSX menubar. I can't move or minimize the display. I've seen this randomly in different dev6 builds, even in the same build. After quitting the first wxgui session and restarting the gui, the titlebar starts below the menubar as it should.

- whenever I click a tab in the "Nviz Tools" window, the display window activates, and I must reactivate the Nviz tools window to change settings.

- the Nviz tools window doesn't start large enough to show the bottom ~60px of the settings and layer properties tabs.

- if I exit NVIZ and start it again in the same wxgui session, I get a second, duplicate Layer Properties tab, a python error:

<Error>: CGContextRestoreGState: invalid context

and the display doesn't draw, except when dragging the view controls (and then only greyscale).

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

[Trillian] What are you supposed to do WITH a maniacally depressed robot?

[Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer...

- HitchHiker's Guide to the Galaxy