#598: MacOS X / OpenGL and Wxpython incompatible
-----------------------+----------------------------------------------------
Reporter: vince | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: NVIZ | Version: svn-trunk
Keywords: | Platform: MacOSX
Cpu: OSX/Intel |
-----------------------+----------------------------------------------------
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?
Replying to [ticket:598 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.
Replying to [comment:1 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.
Replying to [comment:2 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.
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?
Replying to [comment:5 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?
> 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.
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.
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.
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
Replying to [comment:11 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
Replying to [comment:12 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.
Replying to [comment:14 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
Replying to [comment:15 vince]:
> Replying to [comment:14 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.
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.
Replying to [comment:18 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