[GRASS-user] GRASS on Mac OS 10.8.3

GRASS GRASS user
1

I recently upgrade to a new machine that has mac OS 10.8.3 on it (from 10.6). Now, GRASS seems not to be working. What’s the status of GRASS on 10.8.3?
Here are the details.

I tried kyngchaos binary 6.4.2 and if I double click on it, I initially get:

‘/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh’; exit
Rebuilding Addon HTML manual pages index…
Rebuilding Addon menu…
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/osascript) is code signed with entitlements
Python 2.6.8 found.

WELCOME TO GRASS Version 6.4.2 2012

  1. Have at your side all available GRASS tutorials

  2. When working on your location, the following materials
    are extremely useful:

  • A topo map of your area
  • Current catalog of available computer maps
  1. Check the GRASS webpages for feedback mailinglists and more:
    http://www.grass-gis.org
    http://grass.osgeo.org

Hit RETURN to continue

If I then hit return I get:

Starting GRASS …
Traceback (most recent call last):
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py”, line 35, in
from gui_modules import globalvar
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py”, line 76, in
import wx
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/init.py”, line 45, in
from wx._core import *
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py”, line 4, in
import core
ImportError: dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/core.so, 2): no suitable image found. Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/core.so: mach-o, but wrong architecture
Error in GUI startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue…

I then tried downloading the newest 7.0 from cmbarton and ran into similar problems. Any thoughts or suggestions?

Thanks much.

– Adam

2

I figured out the problem and a temporary work around, that I figured I would let people know. But, if anyone has a better solution, I would love to hear it.
The problem seems to be that I have macports installed, and there appears to be an issue with python versions, and where it is being found.

I first tried using the acceptable macports way of changing to different versions of python, but these didn’t help:
sudo port select python python26
sudo port select python python27-apple
Etc, but these didn’t allow either 6.4 or 7.0 to run.

But, if I get rid of all my macports stuff by doing:
Sudo mv /opt/local /opt/local_tmp
Then I can open either GRASS 6.4 or 7.0. I can then move opt/local back and then either GRASS seems to work fine. Even if I quit and restart the gui they are fine.
This was not a problem for me on OS 10.6 and earlier. So, something is different about search paths and/or environmental variables.
Renaming like that is not a viable long term solution, as I need macports stuff a bunch. Any suggestions about how the application is searching and why it is not finding a good version? Or maybe the real problem is that I don’t have the correct port (or version) of something installed in Macports, and if I do then it might be that the macports version is fine, and would work. I believe that there might have been a change between 10.6 and 10.8 related to 32 bit versus 64 bit being default builds, so could there be an issue with which version of wx, or some other library is being searched for?

Any thoughts or guidance?

– Adam

From: Adam Dershowitz <adershowitz@exponent.com>
Date: Monday, April 8, 2013 4:59 PM
To: “grass-user@lists.osgeo.org” <grass-user@lists.osgeo.org>
Subject: GRASS on Mac OS 10.8.3

I recently upgrade to a new machine that has mac OS 10.8.3 on it (from 10.6). Now, GRASS seems not to be working. What’s the status of GRASS on 10.8.3?
Here are the details.

I tried kyngchaos binary 6.4.2 and if I double click on it, I initially get:

‘/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh’; exit
Rebuilding Addon HTML manual pages index…
Rebuilding Addon menu…
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/osascript) is code signed with entitlements
Python 2.6.8 found.

WELCOME TO GRASS Version 6.4.2 2012

  1. Have at your side all available GRASS tutorials

  2. When working on your location, the following materials
    are extremely useful:

  • A topo map of your area
  • Current catalog of available computer maps
  1. Check the GRASS webpages for feedback mailinglists and more:
    http://www.grass-gis.org
    http://grass.osgeo.org

Hit RETURN to continue

If I then hit return I get:

Starting GRASS …
Traceback (most recent call last):
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gis_set.py”, line 35, in
from gui_modules import globalvar
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/gui_modules/globalvar.py”, line 76, in
import wx
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/init.py”, line 45, in
from wx._core import *
File “/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py”, line 4, in
import core
ImportError: dlopen(/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/core.so, 2): no suitable image found. Did find:
/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/core.so: mach-o, but wrong architecture
Error in GUI startup. If necessary, please
report this error to the GRASS developers.
Switching to text mode now.
Hit RETURN to continue…

I then tried downloading the newest 7.0 from cmbarton and ran into similar problems. Any thoughts or suggestions?

Thanks much.

– Adam

3

There was someone else with this problem, but I didn't have a solution then. maybe this will help them.

GRASS (OS X) needs a Python compatible with the bundled wxPython. So far this has been limited to 32bit, though the rest of GRASS can be 64bit. So OS X has a wrapper that forces python to run 32bit, and the startup tries to find a suitable Python.

It's possible that it still somehow executes the Macports Python, and the Macports Python may be 64bit only, then you get the error about the wrong architecture (32bit vs 64bit).

The order for finding Python is:

GRASS_PYTHON
PATH
/Library/Frameworks (the python.org python)
system

Now that I look at it, when finding Python, it doesn't check the available architectures, so it's very possible to find the Macports Python (suspected 64bit only) in the PATH, then fail to run when it's needed.

Try setting GRASS_PYTHON in your .bash_profile to (exactly):

/usr/bin/pythonw2.6

On Apr 9, 2013, at 11:23 AM, Adam Dershowitz wrote:

I figured out the problem and a temporary work around, that I figured I would let people know. But, if anyone has a better solution, I would love to hear it.
The problem seems to be that I have macports installed, and there appears to be an issue with python versions, and where it is being found.

I first tried using the acceptable macports way of changing to different versions of python, but these didn't help:
sudo port select python python26
sudo port select python python27-apple
Etc, but these didn't allow either 6.4 or 7.0 to run.

But, if I get rid of all my macports stuff by doing:
Sudo mv /opt/local /opt/local_tmp
Then I can open either GRASS 6.4 or 7.0. I can then move opt/local back and then either GRASS seems to work fine. Even if I quit and restart the gui they are fine.
This was not a problem for me on OS 10.6 and earlier. So, something is different about search paths and/or environmental variables.
Renaming like that is not a viable long term solution, as I need macports stuff a bunch. Any suggestions about how the application is searching and why it is not finding a good version? Or maybe the real problem is that I don't have the correct port (or version) of something installed in Macports, and if I do then it might be that the macports version is fine, and would work. I believe that there might have been a change between 10.6 and 10.8 related to 32 bit versus 64 bit being default builds, so could there be an issue with which version of wx, or some other library is being searched for?

Any thoughts or guidance?

-- Adam

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

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

4

That did the job.
In my case it was actually in .profile. I think that by default Macports,
on recent systems, builds 64 bit. But, to complicate things, I actually
have a "universal" build of python, but not wxPython. My guess is that
the problem was actually with wx, not with python itself.

Thank you much!

-- Adam

On 4/9/13 5:04 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

There was someone else with this problem, but I didn't have a solution
then. maybe this will help them.

GRASS (OS X) needs a Python compatible with the bundled wxPython. So far
this has been limited to 32bit, though the rest of GRASS can be 64bit.
So OS X has a wrapper that forces python to run 32bit, and the startup
tries to find a suitable Python.

It's possible that it still somehow executes the Macports Python, and the
Macports Python may be 64bit only, then you get the error about the wrong
architecture (32bit vs 64bit).

The order for finding Python is:

GRASS_PYTHON
PATH
/Library/Frameworks (the python.org python)
system

Now that I look at it, when finding Python, it doesn't check the
available architectures, so it's very possible to find the Macports
Python (suspected 64bit only) in the PATH, then fail to run when it's
needed.

Try setting GRASS_PYTHON in your .bash_profile to (exactly):

/usr/bin/pythonw2.6

On Apr 9, 2013, at 11:23 AM, Adam Dershowitz wrote:

I figured out the problem and a temporary work around, that I figured I
would let people know. But, if anyone has a better solution, I would
love to hear it.
The problem seems to be that I have macports installed, and there
appears to be an issue with python versions, and where it is being
found.

I first tried using the acceptable macports way of changing to
different versions of python, but these didn't help:
sudo port select python python26
sudo port select python python27-apple
Etc, but these didn't allow either 6.4 or 7.0 to run.

But, if I get rid of all my macports stuff by doing:
Sudo mv /opt/local /opt/local_tmp
Then I can open either GRASS 6.4 or 7.0. I can then move opt/local
back and then either GRASS seems to work fine. Even if I quit and
restart the gui they are fine.
This was not a problem for me on OS 10.6 and earlier. So, something is
different about search paths and/or environmental variables.
Renaming like that is not a viable long term solution, as I need
macports stuff a bunch. Any suggestions about how the application is
searching and why it is not finding a good version? Or maybe the real
problem is that I don't have the correct port (or version) of something
installed in Macports, and if I do then it might be that the macports
version is fine, and would work. I believe that there might have been a
change between 10.6 and 10.8 related to 32 bit versus 64 bit being
default builds, so could there be an issue with which version of wx, or
some other library is being searched for?

Any thoughts or guidance?

-- Adam

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

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

5

On Apr 9, 2013, at 7:37 PM, Adam Dershowitz wrote:

That did the job.
In my case it was actually in .profile. I think that by default Macports,
on recent systems, builds 64 bit. But, to complicate things, I actually
have a "universal" build of python, but not wxPython. My guess is that
the problem was actually with wx, not with python itself.

Thank you much!

Well, if you have a universal Python in Macports, then it should work because it will execute 32bit. If you mean you have universal Python somewhere else, then Macports 32bit Python is probably found first.

The problem IS python, not wx. GRASS knows wx is 32bit only, it's just that Python somehow executes 64bit (ie from Macports). wxPython has been limited to 32bit on OS X until very recently. My GRASS 6.4.2 includes and the GUI only supports 32bit wxPython. GRASS 6.4.3 has fixes in the GUI to support the development version of wxPython that can be 64bit on OS X, but I don't think Michael has updated yet.

Good to know that GRASS_PYTHON fixes the problem without fuss.

Note: .bash_profile is the standard shell init file on OS X, at least for Terminal. OS X Terminal is an oddball in the loading of init files. On my OS X 10.7 Mac .profile is NOT loaded (it may have been loaded on earlier systems). So it's a good idea to get into the habit of using .bash_profile, even if .profile happens to work for you.

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

Earth: "Mostly harmless"

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

6

On 4/9/13 6:02 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

On Apr 9, 2013, at 7:37 PM, Adam Dershowitz wrote:

That did the job.
In my case it was actually in .profile. I think that by default
Macports,
on recent systems, builds 64 bit. But, to complicate things, I actually
have a "universal" build of python, but not wxPython. My guess is that
the problem was actually with wx, not with python itself.

Thank you much!

Well, if you have a universal Python in Macports, then it should work
because it will execute 32bit. If you mean you have universal Python
somewhere else, then Macports 32bit Python is probably found first.

I did mean that I built Python universal in macports. Although the
macports wx is not universal (and fails to build that way)

The problem IS python, not wx. GRASS knows wx is 32bit only, it's just
that Python somehow executes 64bit (ie from Macports). wxPython has been
limited to 32bit on OS X until very recently. My GRASS 6.4.2 includes
and the GUI only supports 32bit wxPython. GRASS 6.4.3 has fixes in the
GUI to support the development version of wxPython that can be 64bit on
OS X, but I don't think Michael has updated yet.

But, I have found something odd. Again, as the problem is solved, this is
not at all a big deal. But, but just something interesting.
It seems that once I set GRASS_PYTHON (either in .profile or
.bash_profile) that it works. But, if I then comment it out and run GRASS
again, it continues to work fine (6.4.2, or 7.0). Furthermore, in the
terminal that GRASS opens, if I do:
which python, what shows is
/Applications/GRASS-6.4.app/Contents/MacOS/bin/python

And these environmental variables are set in that terminal
GRASS_PYTHON=python
GRASS_PYTHONWX=/usr/bin/pythonw2.6

So, it seems like once I set GRASS_PYTHON a single time, it then saves
that value and uses it, even if GRASS_PYTHON is not set the next time.

Good to know that GRASS_PYTHON fixes the problem without fuss.

Note: .bash_profile is the standard shell init file on OS X, at least for
Terminal. OS X Terminal is an oddball in the loading of init files. On
my OS X 10.7 Mac .profile is NOT loaded (it may have been loaded on
earlier systems). So it's a good idea to get into the habit of using
.bash_profile, even if .profile happens to work for you.

That's what I have done now.

Again, thanks for the help.

--Adam