[GRASS-dev] xganim compilation on GRASS 7

GRASS GRASS developer
1

I updated from the svn trunk and compiled with Mac OS X 10.6.

In addition to v.krige not compiling, with this new update, xganim does not compile. It does compile on GRASS 6.5. Here is the error. It appears to be in ximgview.

  "wxWindow::SetScrollPos(int, int, bool)", referenced from:
      vtable for MyFramein gui.o
      vtable for MyCanvasin gui.o
      vtable for wxStaticTextBasein gui.o
      vtable for wxBitmapButtonBasein gui.o
      vtable for wxButtonBasein gui.o
  "wxTopLevelWindowMac::SetLabel(wxString const&)", referenced from:
      vtable for MyFramein gui.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/xganim] Error 1
make -C ximgview || echo /Users/cmbarton/grass_dev/grass70_dev/visualization/ximgview >> /Users/cmbarton/grass_dev/grass70_dev/error.log
make[1]: Nothing to be done for `first'.
cmb-MBP-2:visualization cmbarton$

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

What's the complete compile command just before that error?

On Jan 3, 2010, at 11:52 AM, Michael Barton wrote:

I updated from the svn trunk and compiled with Mac OS X 10.6.

In addition to v.krige not compiling, with this new update, xganim does not compile. It does compile on GRASS 6.5. Here is the error. It appears to be in ximgview.

"wxWindow::SetScrollPos(int, int, bool)", referenced from:
     vtable for MyFramein gui.o
     vtable for MyCanvasin gui.o
     vtable for wxStaticTextBasein gui.o
     vtable for wxBitmapButtonBasein gui.o
     vtable for wxButtonBasein gui.o
"wxTopLevelWindowMac::SetLabel(wxString const&)", referenced from:
     vtable for MyFramein gui.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/xganim] Error 1
make -C ximgview || echo /Users/cmbarton/grass_dev/grass70_dev/visualization/ximgview >> /Users/cmbarton/grass_dev/grass70_dev/error.log
make[1]: Nothing to be done for `first'.
cmb-MBP-2:visualization cmbarton$

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

3

VERY long command, if I read this correctly. So I'm attaching it as a text file.

Michael

(attachments)

xganim_error.txt (85.3 KB)

4

This is the part:

c++ -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib -o /Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/xganim OBJ.i386-apple-darwin10.2.0/gui.o OBJ.i386-apple-darwin10.2.0/main.o -lgrass_raster -lgrass_gis -L/usr/local/lib/wxPython-unicode-2.8.10.1/lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macud-2.8
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
ld: warning: in /usr/local/lib/wxPython-unicode-2.8.10.1/lib/libwx_macud-2.8.dylib, missing required architecture x86_64 in file

The missing symbol errors were because of the missing arch error. xganim is not getting the arch magic, so is building 64bit by default, which doesn't work for wxpython. Interesting that Quicktime is missing the 64bit arch (same on my Mac), maybe it's because that's the old Quicktime 7.x, and the new Quicktime X is somewhere else...

I'll look at the xganim makefile and try to fix it later today.

On Jan 3, 2010, at 12:15 PM, Michael Barton wrote:

VERY long command, if I read this correctly. So I'm attaching it as a text file.

Michael

<xganim_error.txt>

On Jan 3, 2010, at 11:00 AM, William Kyngesburye wrote:

What's the complete compile command just before that error?

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

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

5

William,

talking about xganim, will you be including xganim in your GRASS64 binaries?
We use it a lot for viewing and browsing the results of simulations and data time series
on our linux machines but the students miss it on Mac and MSwindows.

Also, do you plan to make the wxpython GUI the default as it is in the windows binaries?

thank you,

Helena

On Jan 3, 2010, at 1:36 PM, William Kyngesburye wrote:

This is the part:

c++ -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib -o /Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/xganim OBJ.i386-apple-darwin10.2.0/gui.o OBJ.i386-apple-darwin10.2.0/main.o -lgrass_raster -lgrass_gis -L/usr/local/lib/wxPython-unicode-2.8.10.1/lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macud-2.8
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
ld: warning: in /usr/local/lib/wxPython-unicode-2.8.10.1/lib/libwx_macud-2.8.dylib, missing required architecture x86_64 in file

The missing symbol errors were because of the missing arch error. xganim is not getting the arch magic, so is building 64bit by default, which doesn't work for wxpython. Interesting that Quicktime is missing the 64bit arch (same on my Mac), maybe it's because that's the old Quicktime 7.x, and the new Quicktime X is somewhere else...

I'll look at the xganim makefile and try to fix it later today.

On Jan 3, 2010, at 12:15 PM, Michael Barton wrote:

VERY long command, if I read this correctly. So I'm attaching it as a text file.

Michael

<xganim_error.txt>

On Jan 3, 2010, at 11:00 AM, William Kyngesburye wrote:

What's the complete compile command just before that error?

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

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

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

6

On Jan 3, 2010, at 1:40 PM, Helena Mitasova wrote:

William,

talking about xganim, will you be including xganim in your GRASS64 binaries?
We use it a lot for viewing and browsing the results of simulations and data time series
on our linux machines but the students miss it on Mac and MSwindows.

I really don't want to add the overhead of mo/less-tif in the package.

A possible middle road, if lesstif can be compiled as static libraries, I could build it into the xganim binary. That could cut down on the size since only the parts used by xganim would be (?) included, unless that includes most of lesstif.

Also, do you plan to make the wxpython GUI the default as it is in the windows binaries?

I thought wx gui in 6.x, or at least 6.4, was not quite as complete as in 7 (or 6.5). Or at least incomplete compared to the Tcltk gui. And the plan was to leave tcltk as the default in 6.x and make wx the default in 7.

thank you,

Helena

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

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

7

On Jan 3, 2010, at 12:36 PM, William Kyngesburye wrote:

The missing symbol errors were because of the missing arch error. xganim is not getting the arch magic, so is building 64bit by default, which doesn't work for wxpython. Interesting that Quicktime is missing the 64bit arch (same on my Mac), maybe it's because that's the old Quicktime 7.x, and the new Quicktime X is somewhere else...

I'll look at the xganim makefile and try to fix it later today.

OK, I already took care of it back in Sept, so it should work. Though that is assuming you use the macosx-archs configure option. If you don't, there are no archs to check and none to remove (for wxpython components), and this is especially important on Snow because it compiles 64bit by default, while Leopard and below compile 32bit by default.

Because configure avoids (by convention I think) checking for specific platforms, I didn't do that for the archs and sdk options, so it doesn't check system versions (which would get complicated when considering an SDK that's different than the build system) to force an arch to make sure it all works. So specifying macosx-archs is pretty much necessary to avoid the 32/64bit confusion mess. Make sure you specify both i386 and x86_64.

--with-macosx-archs="i386 x86_64"

On Jan 3, 2010, at 12:15 PM, Michael Barton wrote:

VERY long command, if I read this correctly. So I'm attaching it as a text file.

Michael

<xganim_error.txt>

On Jan 3, 2010, at 11:00 AM, William Kyngesburye wrote:

What's the complete compile command just before that error?

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

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

8

On Jan 3, 2010, at 2:13 PM, William Kyngesburye wrote:

On Jan 3, 2010, at 12:36 PM, William Kyngesburye wrote:

The missing symbol errors were because of the missing arch error. xganim is not getting the arch magic, so is building 64bit by default, which doesn't work for wxpython. Interesting that Quicktime is missing the 64bit arch (same on my Mac), maybe it's because that's the old Quicktime 7.x, and the new Quicktime X is somewhere else...

I'll look at the xganim makefile and try to fix it later today.

OK, I already took care of it back in Sept, so it should work. Though that is assuming you use the macosx-archs configure option. If you don't, there are no archs to check and none to remove (for wxpython components), and this is especially important on Snow because it compiles 64bit by default, while Leopard and below compile 32bit by default.

Because configure avoids (by convention I think) checking for specific platforms, I didn't do that for the archs and sdk options, so it doesn't check system versions (which would get complicated when considering an SDK that's different than the build system) to force an arch to make sure it all works. So specifying macosx-archs is pretty much necessary to avoid the 32/64bit confusion mess. Make sure you specify both i386 and x86_64.

--with-macosx-archs="i386 x86_64"

I'm specifying the archs, using the exact same config string that I used successfully a couple days ago. This string works in 6.5 too. Could this be related to the Mac make file changes you did over the last couple days?

Michael

On Jan 3, 2010, at 12:15 PM, Michael Barton wrote:

VERY long command, if I read this correctly. So I'm attaching it as a text file.

Michael

<xganim_error.txt>

On Jan 3, 2010, at 11:00 AM, William Kyngesburye wrote:

What's the complete compile command just before that error?

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

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy

9

On Jan 3, 2010, at 3:32 PM, Michael Barton wrote:

On Jan 3, 2010, at 2:13 PM, William Kyngesburye wrote:

I'm specifying the archs, using the exact same config string that I used successfully a couple days ago. This string works in 6.5 too. Could this be related to the Mac make file changes you did over the last couple days?

Michael

I thought you were, but this is exactly what would happen if not...

In platform.make, what do you have for LINK_FLAGS, MACOSX_ARCHS and MACOSX_ARCHS_WXPYTHON? Just a check, because if MACOSX_ARCHS_WXPYTHON is wrong, wx nviz and vdigit would have failed also.

... maybe the xganim makefile somehow didn't get updated in your copy of trunk? is this line in the xganim makefile (followed by some subst mangling):

ifneq ($(MACOSX_ARCHS),)

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

All generalizations are dangerous, even this one.

10

On Jan 3, 2010, at 3:22 PM, William Kyngesburye wrote:

On Jan 3, 2010, at 3:32 PM, Michael Barton wrote:

On Jan 3, 2010, at 2:13 PM, William Kyngesburye wrote:

I'm specifying the archs, using the exact same config string that I used successfully a couple days ago. This string works in 6.5 too. Could this be related to the Mac make file changes you did over the last couple days?

Michael

I thought you were, but this is exactly what would happen if not...

In platform.make, what do you have for

LINK_FLAGS

LINK_FLAGS = -arch i386 -arch x86_64

MACOSX_ARCHS

MACOSX_ARCHS = -arch i386 -arch x86_64

MACOSX_ARCHS_WXPYTHON?

MACOSX_ARCHS_WXPYTHON =

That is, there is nothing there. Maybe this is the problem.

Just a check, because if MACOSX_ARCHS_WXPYTHON is wrong, wx nviz and vdigit would have failed also.

... maybe the xganim makefile somehow didn't get updated in your copy of trunk? is this line in the xganim makefile (followed by some subst mangling):

ifneq ($(MACOSX_ARCHS),)

# substitute OSX arch flags for wxpython
ifneq ($(MACOSX_ARCHS),)
CFLAGS := $(subst $(MACOSX_ARCHS),$(CFLAGS)) $(MACOSX_ARCHS_WXPYTHON)
CXXFLAGS := $(subst $(MACOSX_ARCHS),$(CXXFLAGS)) $(MACOSX_ARCHS_WXPYTHON)
LDFLAGS := $(subst $(MACOSX_ARCHS),$(LDFLAGS)) $(MACOSX_ARCHS_WXPYTHON)
endif

Michael

11

On Jan 3, 2010, at 7:48 PM, Michael Barton wrote:

MACOSX_ARCHS_WXPYTHON =

That is, there is nothing there. Maybe this is the problem.

Ah, that's not right. config.log - the arch check for wxpython is at the bottom (no errors would be completely quiet, I didn't put a log message in configure). Any errors?

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

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

12

No error. Here's the configure result.

Michael

GRASS is now configured for: i386-apple-darwin10.2.0

  Source directory: /Users/cmbarton/grass_dev/grass70_dev
  Build directory: /Users/cmbarton/grass_dev/grass70_dev
  Installation directory: ${prefix}/GRASS-7.0.app/Contents/MacOS
  Startup script in directory: ${exec_prefix}/bin
  C compiler: gcc -g -O2 -arch i386 -arch x86_64
  C++ compiler: c++ -arch i386 -arch x86_64
  Building shared libraries: yes
  64bit support:
  OpenGL platform: Aqua

  MacOSX application: yes
  MacOSX architectures: -arch i386 -arch x86_64
  MacOSX SDK:

  NVIZ: yes

  BLAS support: no
  C++ support: yes
  Cairo support: yes
  DWG support: no
  FFMPEG support: no
  FFTW support: yes
  FreeType support: yes
  GDAL support: yes
  GEOS support: yes
  JPEG support: yes
  LAPACK support: no
  Large File support (LFS): yes
  MySQL support: no
  NLS support: no
  ODBC support: yes
  OGR support: yes
  OpenGL support: yes
  PNG support: yes
  PostgreSQL support: no
  Python support: yes
  Readline support: no
  SQLite support: yes
  Tcl/Tk support: yes
  wxWidgets support: yes
  TIFF support: yes
  X11 support: no
  Regex support: yes
  POSIX thread support: no

cmb-MBP-2:grass70_dev cmbarton$

On Jan 3, 2010, at 7:21 PM, William Kyngesburye wrote:

On Jan 3, 2010, at 7:48 PM, Michael Barton wrote:

MACOSX_ARCHS_WXPYTHON =

That is, there is nothing there. Maybe this is the problem.

Ah, that's not right. config.log - the arch check for wxpython is at the bottom (no errors would be completely quiet, I didn't put a log message in configure). Any errors?

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

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

13

no error in config.log? Just checking since this is configure output, not log.

On Jan 3, 2010, at 8:25 PM, Michael Barton wrote:

No error. Here's the configure result.

Michael

GRASS is now configured for: i386-apple-darwin10.2.0

Source directory: /Users/cmbarton/grass_dev/grass70_dev
Build directory: /Users/cmbarton/grass_dev/grass70_dev
Installation directory: ${prefix}/GRASS-7.0.app/Contents/MacOS
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2 -arch i386 -arch x86_64
C++ compiler: c++ -arch i386 -arch x86_64
Building shared libraries: yes
64bit support:
OpenGL platform: Aqua

MacOSX application: yes
MacOSX architectures: -arch i386 -arch x86_64
MacOSX SDK:

NVIZ: yes

BLAS support: no
C++ support: yes
Cairo support: yes
DWG support: no
FFMPEG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GEOS support: yes
JPEG support: yes
LAPACK support: no
Large File support (LFS): yes
MySQL support: no
NLS support: no
ODBC support: yes
OGR support: yes
OpenGL support: yes
PNG support: yes
PostgreSQL support: no
Python support: yes
Readline support: no
SQLite support: yes
Tcl/Tk support: yes
wxWidgets support: yes
TIFF support: yes
X11 support: no
Regex support: yes
POSIX thread support: no

cmb-MBP-2:grass70_dev cmbarton$

On Jan 3, 2010, at 7:21 PM, William Kyngesburye wrote:

On Jan 3, 2010, at 7:48 PM, Michael Barton wrote:

MACOSX_ARCHS_WXPYTHON =

That is, there is nothing there. Maybe this is the problem.

Ah, that's not right. config.log - the arch check for wxpython is at the bottom (no errors would be completely quiet, I didn't put a log message in configure). Any errors?

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

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

14

Hi,

I also have a (different) problem compiling xganim in GRASS 7:

[neteler@north grass70]$ cd /home/neteler/grass70/visualization/xganim
[neteler@north xganim]$ make
if [ "/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim"
!= "" ] ; then GISRC=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70
GISBASE=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu
PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:$PATH"
PYTHONPATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH"
LD_LIBRARY_PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib:"
LC_ALL=C /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim
--html-description < /dev/null | grep -v '</body>\|</html>' >
xganim.tmp.html ; fi
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim: error
while loading shared libraries: libwx_gtk2u-2.8.so.0: cannot open
shared object file: No such file or directory
make: *** [xganim.tmp.html] Error 1
rm xganim.tmp.html

But it is existing:

[neteler@north xganim]$ locate libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0

How to tell GRASS where it is without adding nasty links?

thanks
Markus

15

Markus Neteler wrote:

I also have a (different) problem compiling xganim in GRASS 7:

[neteler@north grass70]$ cd /home/neteler/grass70/visualization/xganim
[neteler@north xganim]$ make

[snip]

LC_ALL=C /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim
--html-description < /dev/null | grep -v '</body>\|</html>' >
xganim.tmp.html ; fi
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim: error
while loading shared libraries: libwx_gtk2u-2.8.so.0: cannot open
shared object file: No such file or directory
make: *** [xganim.tmp.html] Error 1

This isn't a problem compiling it, but running it.

But it is existing:

[neteler@north xganim]$ locate libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0

How to tell GRASS where it is without adding nasty links?

  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/wxPython/lib

before running "make".

Or add /usr/lib/wxPython/lib to /etc/ld.so.conf then run ldconfig (as
root).

-L switches only tell the linker where to look for libraries. The
loader uses $LD_LIBRARY_PATH and ld.so.cache (generated by ldconfig).

Or you can manually hack the definition of WXWIDGETSLIB in
Platform.make to include -Wl,-rpath,/usr/lib/wxPython/lib. This will
embed the path into the executable.

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

16

On Tue, Jan 5, 2010 at 2:16 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

LC_ALL=C /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim
--html-description < /dev/null | grep -v '</body>\|</html>' > xganim.tmp.html ; fi
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/xganim: error
while loading shared libraries: libwx_gtk2u-2.8.so.0: cannot open
shared object file: No such file or directory
make: *** [xganim.tmp.html] Error 1

This isn't a problem compiling it, but running it.

Right.

But it is existing:

[neteler@north xganim]$ locate libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0
/usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0.5.0

How to tell GRASS where it is without adding nasty links?

   export LD\_LIBRARY\_PATH=$LD\_LIBRARY\_PATH:/usr/lib/wxPython/lib

before running "make".

Or add /usr/lib/wxPython/lib to /etc/ld.so.conf then run ldconfig (as
root).

This would be the easiest solution but I am surprised that it is needed.
Do you all have the library in a different place? Problem of packaging
in my distro?

Markus

-L switches only tell the linker where to look for libraries. The
loader uses $LD_LIBRARY_PATH and ld.so.cache (generated by ldconfig).

Or you can manually hack the definition of WXWIDGETSLIB in
Platform.make to include -Wl,-rpath,/usr/lib/wxPython/lib. This will
embed the path into the executable.

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

17

Markus Neteler wrote:

>> How to tell GRASS where it is without adding nasty links?
>
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/wxPython/lib
>
> before running "make".
>
> Or add /usr/lib/wxPython/lib to /etc/ld.so.conf then run ldconfig (as
> root).

This would be the easiest solution but I am surprised that it is needed.
Do you all have the library in a different place? Problem of packaging
in my distro?

The fact that the wxWidgets libraries are in /usr/lib/wxPython
suggests that they're provided solely for use by wxPython. The binary
wxPython modules probably have the path to the wxWidgets libraries
embedded into them.

It's possible that the distribution has a separate wxWidgets package
(although I doubt that GRASS' configure will handle this; we assume
that the same settings are used both for wxPython and wxWidgets).

FWIW, Gentoo puts the wxWidgets libraries in /usr/lib.

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

18

Just a follow up on the Mac installation issues:

as I mentioned several users reported problems switching from tcltk GUI to wxGUI:
after running g.gui in all possible ways they kept getting an error message.
It turns out that the problem was missing FFTW3 library (on Leopard only?)
- after installing the correct version of FFTW3 everything runs fine.

Another most common problem was people forgetting to install Active Tcl
and then complaining that nviz keeps crashing. Or they thought that Active
Tcl is needed only for Tcltk GUI and when they are running wxpython GUI it is not needed.

Everything is written on the web site so there isn't really a problem as long as
the users read carefully the instructions (what nobody does these days).
As more OS versions and GRASS releases have been added to the web page
people simply overlook important issues.

So William and others on Mac, I am wondering whether it would help for future
to have the instructions for Snow Leopard written in a simpler way something like this

For Snow Leopard install:
  - Unix Compatibility Frameworks: SQLite3, FreeType, UnixImageIO, PROJ, GEOS, and GDAL
  - ActiveTcl 8.5 (not 8.6) from ActiveState
  - GRASS.app 64
- sample data set from here: link

(I am not sure I have it right, but I assume that Python, wxPython and FFTW3
does not have to be installed separately)

For older Mac OS X versions I would keep it as is.

I am not sure that this is the best solution, others may have better ideas,

thank you,

Helena

19

On Jan 24, 2010, at 10:55 PM, Helena Mitasova wrote:

Just a follow up on the Mac installation issues:

as I mentioned several users reported problems switching from tcltk GUI to wxGUI:
after running g.gui in all possible ways they kept getting an error message.
It turns out that the problem was missing FFTW3 library (on Leopard only?)
- after installing the correct version of FFTW3 everything runs fine.

Correct. It sounded like a rc6 was imminent, and it may still be, lots of activity in the wingrass build, so I've been holding off on a rebuild of the older Leopard package to fix this.

Another most common problem was people forgetting to install Active Tcl
and then complaining that nviz keeps crashing. Or they thought that Active
Tcl is needed only for Tcltk GUI and when they are running wxpython GUI it is not needed.

I could look at the ActiveState license to see if I can bundle it in GRASS (I used to do that for the X11 TclTk). It's mainly so I have 1 less thing to compile :wink:

Everything is written on the web site so there isn't really a problem as long as
the users read carefully the instructions (what nobody does these days).
As more OS versions and GRASS releases have been added to the web page
people simply overlook important issues.

So William and others on Mac, I am wondering whether it would help for future
to have the instructions for Snow Leopard written in a simpler way something like this

For Snow Leopard install:
- Unix Compatibility Frameworks: SQLite3, FreeType, UnixImageIO, PROJ, GEOS, and GDAL

Even simpler now, I just haven't updated the page yet: FreeType and GDAL Complete.

- ActiveTcl 8.5 (not 8.6) from ActiveState
- GRASS.app 64
- sample data set from here: link

(I am not sure I have it right, but I assume that Python, wxPython and FFTW3
does not have to be installed separately)

For older Mac OS X versions I would keep it as is.

I am not sure that this is the best solution, others may have better ideas,

I hope it will change soon (new version) so this won't be necessary. If it looks like rc6 is still a ways off, I can rebuild.

Thanks for the comments, it's spurred my brain a little to ponder possibilities.

thank you,

Helena

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

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro