[GRASSLIST:2063] Re: [GRASS5] Mac OSX binary install directions

I'm using AquaR version 1.8 from within both versions 5.0.2 (OpenOSX) and 5.7 (CVS). It works perfectly simply by calling /usr/local/bin/R from within GRASS, although when I try and run system() commands from within GRASS 5.7 I get iconv library version mismatch errors:

> system("g.list rast")
dyld: g.list version mismatch for library: /usr/local/lib/libiconv.2.dylib (compatibility version of user: 5.0.0 greater than library's version: 4.0.0)

C.

On Dec 16, 2003, at 8:01 AM, Thomas Adams wrote:

Hamish,

I have done this, but how does one invoke the "Aqua R" from within GRASS using the 'StartR' application?

Tom

Hamish wrote:

[Setting up GRASS on Mac OSX]

3) Install R-statistics[2]
This is optional, but useful for geostats. Click on CRAN, choose a
mirror, click on R Binaries, macosx, and download RAqua.dmg. Double
click on that package and install tcltk, libreadline, and finally
RAqua. This installs the OSX port of R to Applications/StartR.

...

Why did you not install from fink?
This is not at all a criticism, but rather a legitimate query.

Two reasons:

a) I figured the R team had already gone to the trouble to Aqua-fy it,
and the "offical" port would be better supported and more
Mac-integrated.

b) The r-base package isn't yet present in either Fink's stable or
unstable "current-10.3" branch.

I still think the Fink project is brilliant though.

It has been my experience that one of the major sources of confusion
with OSX is that there are several options for installing unix
software (and the fact that some of them work better for particular
packages than others).

Welcome to the wonderful world of UNIX-powered. Confusing versions of
the same thing for over 30 years. Still, I'd rather have 3 chances of
finding a version that does exactly what I want versus 1 generic version
that only partially does. That doesn't mean you can't put together an
intergrated package with the components pre-chosen by an expert of
course.

And if you think the tyranny of choice is bad on OSX, you should give
Linux a try... eg:

[Debian]$ apt-cache search editor | wc -l
    384

regards,
Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia

On Tue, 16 Dec 2003 10:11:53 -0500
"Christopher Fonnesbeck" <chris@fonnesbeck.org> wrote:

I'm using AquaR version 1.8 from within both versions 5.0.2 (OpenOSX)
and 5.7 (CVS). It works perfectly simply by calling /usr/local/bin/R
from within GRASS, although when I try and run system() commands from
within GRASS 5.7 I get iconv library version mismatch errors:

> system("g.list rast")
dyld: g.list version mismatch for library:
/usr/local/lib/libiconv.2.dylib (compatibility version of user: 5.0.0
greater than library's version: 4.0.0)

Maybe it is better to use Fink's r-base package then, where all the
libraries should match.

I seem to remember GRASS's ./configure script failing to find iconv(),
and returning a warning, but the config checks continuing anyway. Later
I saw Fink had installed the iconv package along the way somewhere &
forgot about it. Maybe it still happens? (can someone check please?)

Hamish

Christopher Fonnesbeck wrote:

I'm using AquaR version 1.8 from within both versions 5.0.2 (OpenOSX)
and 5.7 (CVS). It works perfectly simply by calling /usr/local/bin/R
from within GRASS, although when I try and run system() commands from
within GRASS 5.7 I get iconv library version mismatch errors:

> system("g.list rast")
dyld: g.list version mismatch for library:
/usr/local/lib/libiconv.2.dylib (compatibility version of user: 5.0.0
greater than library's version: 4.0.0)

Why on earth is g.list using libiconv? The only program which is meant
to be using libiconv is d.text.freetype; that's the only reason that
the iconv checks exist.

Hmm. Is libiconv a dependency of libintl? That would explain it.

Sometime between 5.0.1 and 5.0.2, $(INTLLIB) was added to the
definition of GISLIB in src/CMD/generic/make.mid (5.0/5.3) and
include/Make/Grass.make.in (5.7). This is bogus; $(INTLLIB) should
only be used if --with-nls was used.

The obvious fix is to move the libintl checks so that they are only
performed if --with-nls is used, and so that INTLLIB is empty
otherwise.

--
Glynn Clements <glynn.clements@virgin.net>