MacOS X / OpenGL and Wxpython incompatible

[vince]

I've tried to add OpenGL support to the build of Grass in order to get nviz.

1. When using the correct solution, that is the Aqua OpenGL, configure complains about not finding glX* functions. In fact, Aqua OpenGL lacks any glX* code.

2; If I back up on the openGL code bundled with X11, first it creates an unnecessary dependency on X11 and second, it does even not compile, due to conflict between X11 OpenGL and wxPython which seems to depend on the old AGL.

In short : it's a mess. Is there any hope to remove glX* calls from nviz?

[kyngchaos]

Are you building 64bit? I had no problem in trunk for 32bit OSX. How did you configure GRASS? The key options are

--without-glw --with-opengl=aqua --with-python --with-wxwidgets=/path/to/wxpython

You can build --with-x at the same time, it's just used for the XDRIVER and shouldn't interfere with the OpenGL detection.

If you configure with tcltk (for the original nviz), you must use an Aqua framework TclTk, since it shares the same OpenGL setting.

[glynn]

Replying to vince:

I've tried to add OpenGL support to the build of Grass in order to get nviz.

1. When using the correct solution, that is the Aqua OpenGL, configure complains about not finding glX* functions. In fact, Aqua OpenGL lacks any glX* code.

Saying "configure complains about ..." isn't actionable information. At a minimum, we need to see the test message ("checking for ...") and the actual error. Better still would be the relevant portion of config.log (from the "checking for ..." to the end of the file).

2; If I back up on the openGL code bundled with X11, first it creates an unnecessary dependency on X11 and second, it does even not compile, due to conflict between X11 OpenGL and wxPython which seems to depend on the old AGL.

In short : it's a mess. Is there any hope to remove glX* calls from nviz?

NVIZ only uses glX* if built --with-opengl=x11 (which is the default; --with-opengl=aqua etc overrides this).

It's entirely possible that some configure check is pulling in some other library with glX* dependencies, but it's impossible to say without knowing the details.

[vince]

Replying to kyngchaos:

If you configure with tcltk (for the original nviz), you must use an Aqua framework TclTk, since it shares the same OpenGL setting.

This is impossible for a 64-bit build. Tk-aqua is not 64-bit capable, because Tk (even the latest version) relies on deprecated Quickdraw API functions that are only available in 32-bit.

[vince]

Replying to glynn:

It's entirely possible that some configure check is pulling in some other library with glX* dependencies, but it's impossible to say without knowing the details.

Ok, I'll try again and give you more detailed informations. Sorry for being too vague.

[hamish]

dumb question: are 64bit binaries even needed for programs which will not load datasets of massive size? or is just 64bit and twice the memory to allocate and move around because 64>32 is somehow interpreted as "more must be better"?

ie is there any real rush or advantage to have 64bit GUI components?

Hamish

[vince]

Replying to hamish:

dumb question: are 64bit binaries even needed for programs which will not load datasets of massive size? or is just 64bit and twice the memory to allocate and move around because 64>32 is somehow interpreted as "more must be better"?

Definitely not. 64-bit, in Intel architectures, is better because all the math instructions will be executed by the SSE2 unit which is far more accurate and stable than the old i387. Then you have a lot of instructions that are simply not available in 32-bit mode, if not the 4 Gb barrier break. Finally, I think we must face it: 64-bit is the future, and MacOS 10.6 will be 64-bit from top to down, so better get prepared for it right now.

ie is there any real rush or advantage to have 64bit GUI components?

None whatsoever. I've already patched configure to strip out -arch x86_64 and -arch ppc64 when checking for Tcl, so now configure runs okay. Next step is to remove those flags from Makefiles where we link against tk. Can someone tell me if this happen outside of GUI functions?

[kyngchaos]

This is impossible for a 64-bit build. Tk-aqua is not 64-bit capable

... I keep forgetting about TclTk. I guess I should add the same arch strip to the nviz makefile that I once had in the wxnviz/vdigit makefile. But as you say, the configure check needs the same. Could you attach a patch here so that someone could try to get it into the source? (I believe a patch to configure.in is preferred)

MacOS 10.6 will be 64-bit from top to down

I keep hearing this rumor, but that doesn't make sense -- there will be a lot of 32bit apps that will stop working that can't or won't be updated by developers. The system may well be all 64bit, but I don't think Apple will drop 32bit, but at least provide a transition in 10.6.

I also heard that PPC support will be dropped. This makes more sense, since we've had the transition time with Rosetta in 10.4 and 10.5.

[kyngchaos]

Vince, could you attach your configure patch (for configure.in, if possible) for stripping 64bit flags when checking for TclTk on OSX? Note: it should only strip when OpenGL=aqua is used, since a 64bit TclTk X11 is possible on OSX, and that option should be left open.

[vince]

This is what I use to strip 64-bit flags off. It is a shell script executed in tclsh by macports.

for mfile in `find ${worksrcpath} -name Makefile -exec grep -l TCLINCDIR {} \;` ; do
  awk '/EXTRA_CFLAGS[ ]*=/ {print "# Strips 64-bit flags" ; print "CFLAGS1 := $(patsubst -arch x86_64,,$(CFLAGS))" ; print "CFLAGS := $(patsubst -arch ppc64,,$(CFLAGS1))" ; print "LDFLAGS1 := $(patsubst -arch x86_64,,$(LDFLAGS))" ; print "LDFLAGS := $(patsubst -arch ppc64,,$(LDFLAGS1))"} ; {print $0}' ${mfile} > ${mfile}.out ;
  rm ${mfile} ;
  mv \${mfile}.out \${mfile} ;
done

Same thing is to do with the xganim Makefile which installs wxpython dependencies.

Also, nviz will not compile anyway. The file togl.c references unknown Tcl-aqua headers, I can't find a 'TkWindow' declaration in any of mine tk headers, neither 'XVisualInfo'.

Also, find attached patch file I use on configure. The first patch is needed by internal Macports mechanism, it is unrelevant to our discussion.

[vince]

Patch used to ignore 64-bits flags in configure

[vince]

Ok, I have a build that goes fine, but wxgrass will not work. I get no image, and the interface is messed up. I have these messages on console :

GRASS 7.0.svn > g.gui wxpython
Traceback (most recent call last):
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/gui_modules/mapdisp_window.py", line 444, in OnPaint
    self.pdc.DrawToDCClipped(dc, rgn)
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/vdigit/grass7_wxvdigit.py", line 389, in DrawToDCClipped
    def DrawToDCClipped(self, *args): return _grass7_wxvdigit.PseudoDC_DrawToDCClipped(self, *args)
TypeError: in method 'PseudoDC_DrawToDCClipped', argument 2 of type 'void *'
Traceback (most recent call last):
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/gui_modules/mapdisp_window.py", line 444, in OnPaint
    self.pdc.DrawToDCClipped(dc, rgn)
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/vdigit/grass7_wxvdigit.py", line 389, in DrawToDCClipped
    def DrawToDCClipped(self, *args): return _grass7_wxvdigit.PseudoDC_DrawToDCClipped(self, *args)
TypeError: in method 'PseudoDC_DrawToDCClipped', argument 2 of type 'void *'
Traceback (most recent call last):
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/gui_modules/mapdisp_window.py", line 444, in OnPaint
    self.pdc.DrawToDCClipped(dc, rgn)
  File "/usr/pkg/share/grass-7.0.svn/etc/wxpython/vdigit/grass7_wxvdigit.py", line 389, in DrawToDCClipped
    def DrawToDCClipped(self, *args): return _grass7_wxvdigit.PseudoDC_DrawToDCClipped(self, *args)
TypeError: in method 'PseudoDC_DrawToDCClipped', argument 2 of type 'void *'
Wed May 13 16:31:41 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:32:22 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:32:26 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:32:29 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:32:33 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:33:27 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:33:37 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context
Wed May 13 16:33:47 vincent.local Python-32[25738] <Error>: CGContextRestoreGState: invalid context

[vince]

Now,on the 6.4.0 RC4 version, I have a grass6_wxnviz that seems ok. Can someone points me how to make it work? If I click on 3Dview, it tells me "Please wait while loading data" and nothing more happens... Thanks

[hamish]

Replying to vince:

Now,on the 6.4.0 RC4 version, I have a grass6_wxnviz that seems ok. Can someone points me how to make it work? If I click on 3Dview, it tells me "Please wait while loading data" and nothing more happens... Thanks

are you sure it's ok? see bug #586.

Hamish

[vince]

Replying to hamish:

are you sure it's ok? see bug #586.

Looks like the same behaviour, but I have the grass6_wxpyhton file, and something happens. The first time I launched it, the module complained about not being able to find the py-OpenGL module, that I had not installed. So I guess it is really working, at least to some point.

[martinl]

Replying to vince: first time I launched it, the module complained about not being able to find the py-OpenGL module,

BTW, you don't need PyOpenGL for running wxGUI Nviz extension. This check has been removed in all active branches. Martin

[vince]

Replying to martinl:

BTW, you don't need PyOpenGL for running wxGUI Nviz extension. This check has been removed in all active branches. Martin

Seems to have made it to 6.4.0. RC4 though. Vincent

[martinl]

Replying to vince:

Replying to martinl:

BTW, you don't need PyOpenGL for running wxGUI Nviz extension. This check has been removed in all active branches. Martin

Seems to have made it to 6.4.0. RC4 though.

yes, the check has been removed after RC4, please use directly code from releasebranch_6_4.

Martin

[vince]

I have done so.

The two bugs I've reported are still there :

# I cannot digitize a layer, I got an error message that no layer is selected

# The grass_nviz won't start

[kyngchaos]

OK, I figured out autoconf, and patched configure and a few makefiles in dev6 branch r37402 so that a 64bit build will work with a 32bit Tcl/Tk Aqua. Try it out. I'll port it to release 6.4 and trunk if there are no problems with compilation.

[vince]

Replying to kyngchaos:

OK, I figured out autoconf, and patched configure and a few makefiles in dev6 branch r37402 so that a 64bit build will work with a 32bit Tcl/Tk Aqua. Try it out. I'll port it to release 6.4 and trunk if there are no problems with compilation.

Great. Was off in vacation, will do that tomorrow. Thanks, I'll keep you posted

[cmbarton]

Replying to vince:

Replying to kyngchaos:

OK, I figured out autoconf, and patched configure and a few makefiles in dev6 branch r37402 so that a 64bit build will work with a 32bit Tcl/Tk Aqua. Try it out. I'll port it to release 6.4 and trunk if there are no problems with compilation.

Great. Was off in vacation, will do that tomorrow. Thanks, I'll keep you posted

I compiled GRASS 6.5 on the Mac OSX 10.5.7, 64bit last night. After the last fix yesterday, it went fine and compiled with no errors.

Everything seems to run OK. I've loaded and viewed maps with the wxPython GUI, viewed a raster DEM in the wxPython 3D view, and loaded maps in TclTk NVIZ. I'm using TclTk 8.5 aqua from ActiveStates.

Unless there is another specific module that I should test, this seems ready for backport. Thanks to all of you who made this work.

Michael

[vince]

Replying to cmbarton:

I compiled GRASS 6.5 on the Mac OSX 10.5.7, 64bit last night. After the last fix yesterday, it went fine and compiled with no errors.

Confirmed.

Everything seems to run OK. I've loaded and viewed maps with the wxPython GUI, viewed a raster DEM in the wxPython 3D view, and loaded maps in TclTk NVIZ. I'm using TclTk 8.5 aqua from ActiveStates.

Not on my side. I have no display. Instead, I got this error which seems to happen also in trunk: Traceback (most recent call last):

File "/usr/pkg/grass-6.5.svn/etc/wxpython/gui_modules/mapdisp_window.py", line 444, in OnPaint

self.pdc.DrawToDCClipped(dc, rgn)

File "/usr/pkg/grass-6.5.svn/etc/wxpython/vdigit/grass6_wxvdigit.py", line 389, in DrawToDCClipped

def DrawToDCClipped(self, *args): return _grass6_wxvdigit.PseudoDC_DrawToDCClipped(self, *args)

TypeError: in method 'PseudoDC_DrawToDCClipped', argument 2 of type 'void *' Since it does not seem connected to this issue, please go ahead and backport on 6.4. Some other issues need to be fixed in 6.5.svn, e.g. reexecuting with GRASS_PYTHON instead of "pythonw" in wxgui/utils.py

[cmbarton]

I know what the problem is here, but am not sure how to fix it on your system.

If you compile vdigit for wxPython, it also creates a local, swig version of PseudoDC and sets a flag so that wxPython uses this local version instead of the generic one. If something goes wrong with your vdigit compiling, this local PsuedoDC is not made, but wxPython still tries to use it. The result is that your display system is non-functional. Hopefully, this helps you troubleshoot a bit. Martin might have more insight into this.

Michael

[kyngchaos]

TclTk 64bit patches ported to trunk r37489 and release 6.4 r37485.

[cmbarton]

I have compiled GRASS 6.5 and 6.4 and it all works fine, including nviz and the wxpython 3D.

Here is what works for me with the newest versions. Note that this is compiled in 64 bit. I'm using OS X 10.5.8, the current frameworks by William Kyngesburye, and Activstates TclTk 8.5 for aqua. Please check to see if this works for you too.

Configure string:

./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 --without-geos --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-python=/usr/bin/python-config --with-wxwidgets=/usr/local/lib/wxPython-unicode-2.8.9.2/bin/wx-config --with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers /Library/Frameworks/Tk.framework/Headers /Library/Frameworks/Tk.framework/PrivateHeaders" --with-macosx-archs="i386,x86_64"

IMPORTANT: after configure, but BEFORE make, edit include/make/platform.make to change the line from

TCLTKLIBS = -ltk -ltcl

to

TCLTKLIBS = -framework Tcl -framework Tk

then run make and sudo make install

Michael

[vince]

I'll try. But not before next week, as I am stuck recompiling a lot of things since I moved up to Snow Leopard... I'll keep you posted.

[kyngchaos]

Vince, is this still a problem?