[GRASS-dev] RC5 on Mac OS X

Greetings,

I just built RC5 here on Mac OS X 10.5.7 using pretty much all of the latest available stable versions of the dependencies.

The build reports "No errors detected." However I have run into two problems. When I launch GRASS, I get the error:

WARNING: Vector digitizer is not available (dlopen(/Library/OpenOSX/grass/grass 6.4.0RC5/etc/wxpython/vdigit/_grass6_wxvdigit.so, 2):
Symbol not found: __ZN12wxStringBase8InitWithEPKcmm
   Referenced from: /Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/vdigit/_grass6_wxvdigit.so
   Expected in: dynamic lookup

The symbol has an address in libwx:

nm libwx_base_carbon-2.8.0.6.0.dylib | grep ZN12wxStringBase8InitWithEPKcmm

0005f320 T __ZN12wxStringBase8InitWithEPKcmm

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I built the aqua version of Tcl/Tk 8.5.7 which runs fine, installed wxPython 2.8.10.1, numpy 1.3.0, PyOpenGL 3.0.1a3 and used the --with-opengl=aqua flag when running configure.

Any ideas?

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

The wxpython you compile GRASS with, if you spell out a custom path for it in configuration, may not be the wxpython that is found when GRASS runs, depending on which Python is found at runtime.

Are you using a wxpython binary install or your own compiled version? I have not seen libwx_base_* as a normal OSX prefix for wx libraries, they're usually libwx_macud_*.

You could try forcing the Python you want by setting GRASS_PYTHON in your shell init, or in grass.sh.

On Aug 30, 2009, at 6:30 AM, Jeshua Lacock wrote:

Greetings,

I just built RC5 here on Mac OS X 10.5.7 using pretty much all of the latest available stable versions of the dependencies.

The build reports "No errors detected." However I have run into two problems. When I launch GRASS, I get the error:

WARNING: Vector digitizer is not available (dlopen(/Library/OpenOSX/grass/grass 6.4.0RC5/etc/wxpython/vdigit/_grass6_wxvdigit.so, 2):
Symbol not found: __ZN12wxStringBase8InitWithEPKcmm
Referenced from: /Library/OpenOSX/grass/grass-6.4.0RC5/etc/wxpython/vdigit/_grass6_wxvdigit.so
Expected in: dynamic lookup

The symbol has an address in libwx:

nm libwx_base_carbon-2.8.0.6.0.dylib | grep ZN12wxStringBase8InitWithEPKcmm

0005f320 T __ZN12wxStringBase8InitWithEPKcmm

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I built the aqua version of Tcl/Tk 8.5.7 which runs fine, installed wxPython 2.8.10.1, numpy 1.3.0, PyOpenGL 3.0.1a3 and used the --with-opengl=aqua flag when running configure.

Any ideas?

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

-----
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

On Aug 30, 2009, at 9:56 AM, William Kyngesburye wrote:

The wxpython you compile GRASS with, if you spell out a custom path for it in configuration, may not be the wxpython that is found when GRASS runs, depending on which Python is found at runtime.

Thanks William,

I am using the version of Python that ships with Mac OS X. I believe it is the only version of wxpython and Python installed on my system.

Seems like it is working right, the GUI works (which requires wxpython).

Are you using a wxpython binary install or your own compiled version? I have not seen libwx_base_* as a normal OSX prefix for wx libraries, they're usually libwx_macud_*.

I looked at the instructions a bit better, and noticed that they recommend to use the "--enable-monolithic" flag on Mac OS X which creates the libraries that you are accustomed to.

But after making sure the old libs were deleted and rebuilding GRASS I still get the same exact errors.

:frowning:

You could try forcing the Python you want by setting GRASS_PYTHON in your shell init, or in grass.sh.

I only have one copy of Python installed on this machine - the version that ships with Mac OS X. Would I set it to that?

Best,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I just tried running GDB, but I was not able to find out any additional information. After it crashes it stops running so doing a backtrace just reveals that there is no stack.

Does anyone know what library that it is not finding might be? That might help narrow things down a bit.

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:

On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I just tried running GDB, but I was not able to find out any additional information. After it crashes it stops running so doing a backtrace just reveals that there is no stack.

Does anyone know what library that it is not finding might be? That might help narrow things down a bit.

Note that I am able to start nviz by issuing the command in the terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" - it is just blank.

Any ideas?

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Sep 1, 2009, at 3:32 AM, Jeshua Lacock wrote:

On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:

On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I just tried running GDB, but I was not able to find out any additional information. After it crashes it stops running so doing a backtrace just reveals that there is no stack.

Does anyone know what library that it is not finding might be? That might help narrow things down a bit.

Note that I am able to start nviz by issuing the command in the terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" - it is just blank.

Wow - how embarrassing! I did not have the region set right. So niviz is in-fact working for me.

Which leads me to the question, how is launching it from the GUI (selecting 3D view) different than from the command line?

Sorry for my monothread!

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

Jeshua,

can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

  this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the problem.
It used to run, so I am not sure whether there is a problem with my data set
or with my version of GRASS (I am using William's grass64 binary).

thank you

Helena

On Sep 1, 2009, at 5:42 AM, Jeshua Lacock wrote:

On Sep 1, 2009, at 3:32 AM, Jeshua Lacock wrote:

On Sep 1, 2009, at 2:29 AM, Jeshua Lacock wrote:

On Aug 30, 2009, at 5:30 AM, Jeshua Lacock wrote:

And when I attempt to launch NVIZ (by choosing "3D view" from the map display), the GUI crashes and in the terminal reports:

dyld: lazy symbol binding failed: image not found for lazy pointer at 0x286d054
dyld: image not found for lazy pointer at 0x286d054

I just tried running GDB, but I was not able to find out any additional information. After it crashes it stops running so doing a backtrace just reveals that there is no stack.

Does anyone know what library that it is not finding might be? That might help narrow things down a bit.

Note that I am able to start nviz by issuing the command in the terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" - it is just blank.

Wow - how embarrassing! I did not have the region set right. So niviz is in-fact working for me.

Which leads me to the question, how is launching it from the GUI (selecting 3D view) different than from the command line?

Sorry for my monothread!

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Sep 1, 2009, at 4:42 AM, Jeshua Lacock wrote:

Note that I am able to start nviz by issuing the command in the terminal. The GUI loads, but my dem is not drawn when I hit "DRAW" - it is just blank.

Wow - how embarrassing! I did not have the region set right. So niviz is in-fact working for me.

Which leads me to the question, how is launching it from the GUI (selecting 3D view) different than from the command line?

Sorry for my monothread!

nviz from the terminal is opening the TclTk NVIZ. In the Python GUI it's the wxPython NVIZ.

Are you using a wxpython binary install or your own compiled version? I have not seen libwx_base_* as a normal OSX prefix for wx libraries, they're usually libwx_macud_*.

I looked at the instructions a bit better, and noticed that they recommend to use the "--enable-monolithic" flag on Mac OS X which creates the libraries that you are accustomed to.

But after making sure the old libs were deleted and rebuilding GRASS I still get the same exact errors.

So, you're saying that you did compile your own wxPython? But then you rebuilt with the monolithic option? Did you then distclean GRASS before recompiling it?

3 things to try:

- make sure you have /Library/Python/2.5/site-packages/wxredirect.pth, maybe your wxpython build didn't install this for some reason. and make sure that you don't have any older wxpython junk in your site-packages.

- the system wxpython meets the minimum requirements. Try deleting your wxpython and reconfiguring GRASS to use the system wxPython.

- try installing the latest wxPython binaries from the wxpython site, instead of compiling your own.

You could try forcing the Python you want by setting GRASS_PYTHON in your shell init, or in grass.sh.

I only have one copy of Python installed on this machine - the version that ships with Mac OS X. Would I set it to that?

No need to set it then.

-----
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

On Sep 1, 2009, at 7:48 AM, Helena Mitasova wrote:

can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the problem.
It used to run, so I am not sure whether there is a problem with my data set
or with my version of GRASS (I am using William's grass64 binary).

Hi Helena,

I just did and I got the same error, so it is safe to say that it is not because of William's binaries.

I am not familiar with a "reclass raster", have you attempted to use another reclass raster?

Best,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Sep 1, 2009, at 9:04 AM, William Kyngesburye wrote:

Which leads me to the question, how is launching it from the GUI (selecting 3D view) different than from the command line?

nviz from the terminal is opening the TclTk NVIZ. In the Python GUI it's the wxPython NVIZ.

I see, that makes sense.

Should _grass6_wxvdigit.so and _grass6_wxnviz.so be linked to libwx_mac? Because they are not, and that is where the symbol that _grass6_wxvdigit is failing to find lives.

Are you using a wxpython binary install or your own compiled version? I have not seen libwx_base_* as a normal OSX prefix for wx libraries, they're usually libwx_macud_*.

I looked at the instructions a bit better, and noticed that they recommend to use the "--enable-monolithic" flag on Mac OS X which creates the libraries that you are accustomed to.

But after making sure the old libs were deleted and rebuilding GRASS I still get the same exact errors.

So, you're saying that you did compile your own wxPython? But then you rebuilt with the monolithic option? Did you then distclean GRASS before recompiling it?

3 things to try:

- make sure you have /Library/Python/2.5/site-packages/wxredirect.pth, maybe your wxpython build didn't install this for some reason. and make sure that you don't have any older wxpython junk in your site-packages.

Odd - I don't have that file in my source or in /Library:

find /usr/src/wxPython-src-2.8.10.1/ -name "*wxredirect*"
find /Library -name "*wxredirect*"

Both returns nothing.

- the system wxpython meets the minimum requirements. Try deleting your wxpython and reconfiguring GRASS to use the system wxPython.

I did not know that wxpython was included with Mac OS X, thanks.

- try installing the latest wxPython binaries from the wxpython site, instead of compiling your own.

I will try both of these suggestions now...

Thanks,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Sep 1, 2009, at 9:04 AM, William Kyngesburye wrote:

- the system wxpython meets the minimum requirements. Try deleting your wxpython and reconfiguring GRASS to use the system wxPython.

That did the trick, thanks! Both wx-digit and wx-nviz both work now.

I *suspect* that means the wxpython GUI is not compatible with 2.8.10.

Cheers,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

On Sep 1, 2009, at 4:52 PM, Jeshua Lacock wrote:

Should _grass6_wxvdigit.so and _grass6_wxnviz.so be linked to libwx_mac? Because they are not, and that is where the symbol that _grass6_wxvdigit is failing to find lives.

Maybe. I'm not quite sure about some of the finer details of linking libraries and loading extensions. I think I went to the extreme and assumed wxlibrary symbols needed by the grass nviz module would be available because the wxpython modules would have loaded them. Really, if a module needs a symbol directly, it should link the library itself.

I'll look into it later, busy figuring out Snow Leopard stuff now...

- make sure you have /Library/Python/2.5/site-packages/wxredirect.pth, maybe your wxpython build didn't install this for some reason. and make sure that you don't have any older wxpython junk in your site-packages.

Odd - I don't have that file in my source or in /Library:

find /usr/src/wxPython-src-2.8.10.1/ -name "*wxredirect*"
find /Library -name "*wxredirect*"

Both returns nothing.

I think it's generated during the install process, so you won't find it in the source. Do you have any wx files at all in your site-packages?

-----
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

On Sep 1, 2009, at 5:12 PM, Jeshua Lacock wrote:

That did the trick, thanks! Both wx-digit and wx-nviz both work now.

I *suspect* that means the wxpython GUI is not compatible with 2.8.10.

It works fine with 2.8.10. I think your compiled wxpython didn't install correctly. Try installing the latest wxpython binary package from wxpython.org.

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

"The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects."

- the wisdom of Tarzan

I just tried in on wingrass and it has the same problem - it actually drapes the raster over the surface but then it gets stuck.

Reclass rasters should probably go away in future releases but they are from the times
when disk space was valuable. Such rasters are derived by reclassification of another map
  and only the reclass table is stored - but if you accidentally
remove the original raster you practically lose your reclassed map as well.

landclass96 is a reclass of landuse96_28m which is in PERMANENT,
I will double check the original raster but it runs fine in GRASS63.
You are right that it would be useful to generate some other reclass maps to test
whether this is a data issue or a new bug in nviz,

thanks for trying it,

Helena

On Sep 1, 2009, at 5:36 PM, Jeshua Lacock wrote:

On Sep 1, 2009, at 7:48 AM, Helena Mitasova wrote:

can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the problem.
It used to run, so I am not sure whether there is a problem with my data set
or with my version of GRASS (I am using William's grass64 binary).

Hi Helena,

I just did and I got the same error, so it is safe to say that it is not because of William's binaries.

I am not familiar with a "reclass raster", have you attempted to use another reclass raster?

Best,

Jeshua Lacock, Owner
<http://OpenOSX.com>
phone: 208.462.4171

Helena wrote:

can you please test one additional nviz issue?

with nc_spm_08 data set, what happens when you run

g.region rast=elevation
nviz elevation col=landclass96

this used to run, but now I get:

Warning: loading failed
ERROR:

landclass96 is a reclass raster, making it regular raster, fixes the
problem.
It used to run, so I am not sure whether there is a problem with my
data set or with my version of GRASS (I am using William's
grass64 binary).

I can see the same thing on linux 64bit.

The warning is because Gs_loadmap_as_char() in lib/ogsf/Gs3.c returns -2,
which apparently means:
   \return -2 if read ok, but 1 or more values
   were too large (small) to fit into an unsigned char.
   (in which case the max (min) char is used)
....
    return (overflow ? -2 : 1);
}

... which points to a 32bit/64bit sizeof() snafu ..

Indeed, lib/ogsf/ makes extensive use of "long".

grass65/lib/ogsf$ grep -w long * | wc -l
58

a small C program:
#include <stdio.h>

int main()
{
   printf("sizeof(int) = %d\n", sizeof(int));
   printf("sizeof(long) = %d\n", sizeof(long));
   printf("sizeof(long long) = %d\n", sizeof(long long));
   printf("sizeof(float) = %d\n", sizeof(float));
   printf("sizeof(double) = %d\n", sizeof(double));

   return 0;
}

on 32bit i686 linux + gcc:
sizeof(int) = 4
sizeof(long) = 4
sizeof(long long) = 8
sizeof(float) = 4
sizeof(double) = 8

on 64bit amd64 linux + gcc:
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(float) = 4
sizeof(double) = 8

which would be a great theory if it worked on 32bit linux, but of
course it crashes there too, so dunno.

Hamish

Helena wrote:

Reclass rasters should probably go away in future releases but they
are from the times when disk space was valuable.

It still is valuable, say you have 50 reclass maps from one huge
raster... the disk space problem scales as datasets get larger.

I will double check the original raster but it runs fine in GRASS63.

I can confirm it works in 6.3.0 but fails in latest 6.4.0svn and grass 7.

I would note in the 6.3.0 terminal output the "loading error" text:
....
Loading Data
building color table
loading error
recalculating normals...
D3/3: calling Togl_SwapBuffers...
....

so maybe the problem existed back then but just wasn't caught.

Hamish

Hamish wrote:

> can you please test one additional nviz issue?
>
> with nc_spm_08 data set, what happens when you run
>
> g.region rast=elevation
> nviz elevation col=landclass96
>
> this used to run, but now I get:
>
> Warning: loading failed
> ERROR:
>
> landclass96 is a reclass raster, making it regular raster, fixes the
> problem.
> It used to run, so I am not sure whether there is a problem with my
> data set or with my version of GRASS (I am using William's
> grass64 binary).

I can see the same thing on linux 64bit.

The warning is because Gs_loadmap_as_char() in lib/ogsf/Gs3.c returns -2,
which apparently means:
   \return -2 if read ok, but 1 or more values
   were too large (small) to fit into an unsigned char.
   (in which case the max (min) char is used)
....
    return (overflow ? -2 : 1);
}

... which points to a 32bit/64bit sizeof() snafu ..

Huh?

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