[GRASS-dev] any idea about these python libraries?

The libraries listed below are in /usr/lib on my Mac.

They are NOT in the /usr/lib of the Mac of a colleague here in Valencia.

Many of these libraries are also in /usr/local/lib/wxPython-unicode-2.8.9.2/lib on my Mac and that of my colleague

They are NOT needed in order for me to compile GRASS without errors

The ARE needed for me to run the wxPython GUI 3D display and digitizer. My colleagues also cannot run the wxPython 3d display and digitizer without these files.

So my questions are:

  1. Are these on in your /usr/lib William?

  2. Do I somehow have some legacy files that I’m compiling against (even if I remove them from /usr/lib) or

  3. Is my colleague Agustin somehow missing these files that should have been installed on his Mac?

Thanks
Michael

========== libraries follow =================

ibwx_macud-2.8.0.1.1.dylib
libwx_macud_gl-2.8.dylib
libwx_macud-2.8.0.dylib
libwx_macud_netutils-2.8.0.1.0.dylib
libwx_macud-2.8.dylib
libwx_macud_netutils-2.8.0.dylib
libwx_macud_fl-2.8.0.1.0.dylib
libwx_macud_netutils-2.8.dylib
libwx_macud_fl-2.8.0.dylib
libwx_macud_ogl-2.8.0.1.0.dylib
libwx_macud_fl-2.8.dylib
libwx_macud_ogl-2.8.0.dylib
libwx_macud_foldbar-2.8.0.1.0.dylib
libwx_macud_ogl-2.8.dylib
libwx_macud_foldbar-2.8.0.dylib
libwx_macud_plot-2.8.0.1.0.dylib
libwx_macud_foldbar-2.8.dylib
libwx_macud_plot-2.8.0.dylib
libwx_macud_gizmos-2.8.0.1.0.dylib
libwx_macud_plot-2.8.dylib
libwx_macud_gizmos-2.8.0.dylib
libwx_macud_stc-2.8.0.1.0.dylib
libwx_macud_gizmos-2.8.dylib
libwx_macud_stc-2.8.0.dylib
libwx_macud_gizmos_xrc-2.8.0.1.0.dylib
libwx_macud_stc-2.8.dylib
libwx_macud_gizmos_xrc-2.8.0.dylib
libwx_macud_svg-2.8.0.1.0.dylib
libwx_macud_gizmos_xrc-2.8.dylib
libwx_macud_svg-2.8.0.dylib
libwx_macud_gl-2.8.0.1.1.dylib
libwx_macud_svg-2.8.dylib


C. Michael Barton, Professor of Anthropology

Director of Graduate Studies, School of Human Evolution & Social Change

Director, Center for Social Dynamics & Complexity

Arizona State University

Phone: 480-965-6262

Fax: 480-965-7671

www: <www.public.asu.edu/~cmbarton>

On May 29, 2009, at 5:18 PM, Michael Barton wrote:

The libraries listed below are in /usr/lib on my Mac.

They are NOT in the /usr/lib of the Mac of a colleague here in Valencia.

Many of these libraries are also in /usr/local/lib/wxPython-unicode-2.8.9.2/lib on my Mac and that of my colleague

They are NOT needed in order for me to compile GRASS without errors

The ARE needed for me to run the wxPython GUI 3D display and digitizer. My colleagues also cannot run the wxPython 3d display and digitizer without these files.

So my questions are:

1. Are these on in your /usr/lib William?

Yes. These are for the system copy of wxPython. Don't delete them.

2. Do I somehow have some legacy files that I'm compiling against (even if I remove them from /usr/lib) or

Nothing in GRASS should link directly to them on OSX. Only wxpython modules should link to the wx libraries, vdigit just loads wxpython.

3. Is my colleague Agustin somehow missing these files that should have been installed on his Mac?

I need to look at this closer, later, gotta go.

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

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

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

On May 29, 2009, at 5:37 PM, William Kyngesburye wrote:

On May 29, 2009, at 5:18 PM, Michael Barton wrote:

The libraries listed below are in /usr/lib on my Mac.

They are NOT in the /usr/lib of the Mac of a colleague here in Valencia.

Many of these libraries are also in /usr/local/lib/wxPython-unicode-2.8.9.2/lib on my Mac and that of my colleague

They are NOT needed in order for me to compile GRASS without errors

The ARE needed for me to run the wxPython GUI 3D display and digitizer. My colleagues also cannot run the wxPython 3d display and digitizer without these files.

So my questions are:

1. Are these on in your /usr/lib William?

Yes. These are for the system copy of wxPython. Don't delete them.

2. Do I somehow have some legacy files that I'm compiling against (even if I remove them from /usr/lib) or

Nothing in GRASS should link directly to them on OSX. Only wxpython modules should link to the wx libraries, vdigit just loads wxpython.

I found that wx nviz and vdigit *did* link the wx libraries - a reversion in the switch to setup.py that I missed. Fixed now in SVN.

It doesn't hurt to link the wx libraries, but maybe, if there are multiple copies of wxpython installed (system and /usr/local), the one that was linked at compile time is different than the one found in sys.path at run time. This would cause trouble.

GRASS should compile with the one found using the --with-wxwidgets flag.

3. Is my colleague Agustin somehow missing these files that should have been installed on his Mac?

I need to look at this closer, later, gotta go.

If these are missing in /usr/lib, the only safe way to restore them is to reinstall the system.

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

Thanks. I just updated and recompiled. Hopefully that will solve Agustin and perhaps others' problems running the digitizer and 3D display.

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

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On May 30, 2009, at 8:59 AM, William Kyngesburye wrote:

On May 29, 2009, at 5:37 PM, William Kyngesburye wrote:

On May 29, 2009, at 5:18 PM, Michael Barton wrote:

The libraries listed below are in /usr/lib on my Mac.

They are NOT in the /usr/lib of the Mac of a colleague here in
Valencia.

Many of these libraries are also in /usr/local/lib/wxPython-
unicode-2.8.9.2/lib on my Mac and that of my colleague

They are NOT needed in order for me to compile GRASS without errors

The ARE needed for me to run the wxPython GUI 3D display and
digitizer. My colleagues also cannot run the wxPython 3d display
and digitizer without these files.

So my questions are:

1. Are these on in your /usr/lib William?

Yes. These are for the system copy of wxPython. Don't delete them.

2. Do I somehow have some legacy files that I'm compiling against
(even if I remove them from /usr/lib) or

Nothing in GRASS should link directly to them on OSX. Only wxpython
modules should link to the wx libraries, vdigit just loads wxpython.

I found that wx nviz and vdigit *did* link the wx libraries - a
reversion in the switch to setup.py that I missed. Fixed now in SVN.

It doesn't hurt to link the wx libraries, but maybe, if there are
multiple copies of wxpython installed (system and /usr/local), the one
that was linked at compile time is different than the one found in
sys.path at run time. This would cause trouble.

GRASS should compile with the one found using the --with-wxwidgets flag.

3. Is my colleague Agustin somehow missing these files that should
have been installed on his Mac?

I need to look at this closer, later, gotta go.

If these are missing in /usr/lib, the only safe way to restore them is
to reinstall the system.

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

William Kyngesburye wrote:

> Nothing in GRASS should link directly to them on OSX. Only wxpython
> modules should link to the wx libraries, vdigit just loads wxpython.
>
I found that wx nviz and vdigit *did* link the wx libraries - a
reversion in the switch to setup.py that I missed. Fixed now in SVN.

Code which calls wx functions directly *should* be explicitly linking
against the wx libraries.

Even if you can rely upon wx having been loaded by wxPython, there are
other issues, e.g. Gentoo's revdep-rebuild relies upon "ldd" output
for dependency tracking, and won't be able to detect that these files
need to be re-built if wx is updated unless they are explicitly linked
against the wx libraries.

It doesn't hurt to link the wx libraries, but maybe, if there are
multiple copies of wxpython installed (system and /usr/local), the one
that was linked at compile time is different than the one found in
sys.path at run time. This would cause trouble.

There isn't anything you can do about this; even if you force e.g.
the vdigit module to use a specific version of wx with e.g. -rpath, if
wxPython itself loads a different version, either vdigit will end up
using that version (wrong) or you will end up with two different
versions in memory (also wrong).

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

I think the issue is that wx libraries are in 2 places on the Mac: 1) in /usr/lib/ installed with the system and 2) in /usr/local/lib/wx-python... for the libraries that are installed with a new installation of wxPython.

The latter is what is pointed to in the config statement and it seems that these should be the libraries linked. However, vdigit and wx3D were somehow linking the older system libraries and NOT linking with the ones specified in configure. Other than vdigit and wx3D, wxPython is linking with the ones specified in configure.

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

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On May 31, 2009, at 1:51 AM, Glynn Clements wrote:

William Kyngesburye wrote:

Nothing in GRASS should link directly to them on OSX. Only wxpython
modules should link to the wx libraries, vdigit just loads wxpython.

I found that wx nviz and vdigit *did* link the wx libraries - a
reversion in the switch to setup.py that I missed. Fixed now in SVN.

Code which calls wx functions directly *should* be explicitly linking
against the wx libraries.

Even if you can rely upon wx having been loaded by wxPython, there are
other issues, e.g. Gentoo's revdep-rebuild relies upon "ldd" output
for dependency tracking, and won't be able to detect that these files
need to be re-built if wx is updated unless they are explicitly linked
against the wx libraries.

It doesn't hurt to link the wx libraries, but maybe, if there are
multiple copies of wxpython installed (system and /usr/local), the one
that was linked at compile time is different than the one found in
sys.path at run time. This would cause trouble.

There isn't anything you can do about this; even if you force e.g.
the vdigit module to use a specific version of wx with e.g. -rpath, if
wxPython itself loads a different version, either vdigit will end up
using that version (wrong) or you will end up with two different
versions in memory (also wrong).

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

You can check which wx libraries are linked with (before my change in SVN):

otool -L /path/to/grass/etc/wxpython/nviz/_grass6_wxnviz.so

And compare that with the sys.path in Python - the wxpython path for the installed new wxpython should be before any system path.

On May 31, 2009, at 4:22 AM, Michael Barton wrote:

I think the issue is that wx libraries are in 2 places on the Mac: 1) in /usr/lib/ installed with the system and 2) in /usr/local/lib/wx-python... for the libraries that are installed with a new installation of wxPython.

The latter is what is pointed to in the config statement and it seems that these should be the libraries linked. However, vdigit and wx3D were somehow linking the older system libraries and NOT linking with the ones specified in configure. Other than vdigit and wx3D, wxPython is linking with the ones specified in configure.

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

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

On May 31, 2009, at 1:51 AM, Glynn Clements wrote:

There isn't anything you can do about this; even if you force e.g.
the vdigit module to use a specific version of wx with e.g. -rpath, if
wxPython itself loads a different version, either vdigit will end up
using that version (wrong) or you will end up with two different
versions in memory (also wrong).

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

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

Earth: "Mostly harmless"

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

On May 31, 2009, at 3:51 AM, Glynn Clements wrote:

I found that wx nviz and vdigit *did* link the wx libraries - a
reversion in the switch to setup.py that I missed. Fixed now in SVN.

Code which calls wx functions directly *should* be explicitly linking
against the wx libraries.

Even if you can rely upon wx having been loaded by wxPython, there are
other issues, e.g. Gentoo's revdep-rebuild relies upon "ldd" output
for dependency tracking, and won't be able to detect that these files
need to be re-built if wx is updated unless they are explicitly linked
against the wx libraries.

Do nviz and vdigit use wx libraries directly? (as opposed to wxpython modules)

If so, then due to the way the wxpython packagers build the libraries, a GRASS build would be tied to an exact version of wxpython. This makes it difficult to distribute GRASS binaries where the user is required to download an exact version of wxpython, and they decide to update later. Or even with a make install'd GRASS, if you update wxpython, even a minor point update, it'll break the GRASS GUI unless you remember to rebuild GRASS.

I made it possible to bundle wxpython in the GRASS app package for a distribution, so the user doesn't have to worry about downloading any wxpython. I guess this would help the exact version linking problem also. Maybe I should move the bundle step to the install target as well...

Michael, Agustin - my current 6.4RC4 installer uses a bundled wxpython. Does vdigit there work for you?

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

William Kyngesburye wrote:

>> I found that wx nviz and vdigit *did* link the wx libraries - a
>> reversion in the switch to setup.py that I missed. Fixed now in SVN.
>
> Code which calls wx functions directly *should* be explicitly linking
> against the wx libraries.
>
> Even if you can rely upon wx having been loaded by wxPython, there are
> other issues, e.g. Gentoo's revdep-rebuild relies upon "ldd" output
> for dependency tracking, and won't be able to detect that these files
> need to be re-built if wx is updated unless they are explicitly linked
> against the wx libraries.

Do nviz and vdigit use wx libraries directly? (as opposed to wxpython
modules)

vdigit actually uses it, while nviz gets a dependency due to including
wx headers from nviz.h. If I remove the inclusion of wx headers from
nviz.h, nviz still compiles okay and loses the wx dependency.

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