[GRASS-user] GRASSsvn release branch g.region broken

GRASS GRASS user
1

I downloaded and compiled GRASS svn today, and g.region was broken. Any
help would be greatly appreciated.

Stephen

2

ssefick wrote:

I downloaded and compiled GRASS svn
today, and g.region was broken. Any
help would be greatly appreciated.

please refer to the "Please be specific in your questions." section here:
  http://grass.osgeo.org/wiki/Mailing_list_etiquette

what version & revision of svn?
is this Linux/Mac/Windows? which version/distro?
what was the exact error message? how was it broken?
what's the map projection of the location?
etc.

thanks,
Hamish

3

Reply in-line below

On Wed, Oct 6, 2010 at 6:22 PM, Hamish <hamish_b@yahoo.com> wrote:

ssefick wrote:

I downloaded and compiled GRASS svn
today, and g.region was broken. Any
help would be greatly appreciated.

please refer to the "Please be specific in your questions." section here:
http://grass.osgeo.org/wiki/Mailing_list_etiquette

what version & revision of svn?
is this Linux/Mac/Windows? which version/distro?

Ubuntu Linux 10.04.1

what was the exact error message?

ERROR: Incompatible library version for module. You need to rebuild GRASS
       or untangle multiple installations

how was it broken?

svn checkout and install of the 6.4 release branch

what's the map projection of the location?

It happens both in an old location that is nad83 utm zone 17
and a new location that is nad86 NC State Plane (I will provide the
exact projection information if this will help)

etc.

built new grass64

Error

uninstalled synaptic grass

re-built grass

Error

Re-installed synaptic grass to get some work done

went home and popped open a cold and frost... Probably too much info.
Thanks for all of the help, and if anybody needs anything please let
me know.

kindest regards,

--
Stephen Sefick
____________________________________
| Auburn University |
| Department of Biological Sciences |
| 331 Funchess Hall |
| Auburn, Alabama |
| 36849 |
|___________________________________|
| sas0025@auburn.edu |
| http://www.auburn.edu/~sas0025 |
|___________________________________|

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods. We are mammals, and have not exhausted the
annoying little problems of being mammals.

                            \-K\. Mullis

"A big computer, a complex algorithm and a long time does not equal science."

                          \-Robert Gentleman
4

Hamish:

> what was the exact error message?

Stephen:

ERROR: Incompatible library version for module. You need to rebuild GRASS
       or untangle multiple installations

> how was it broken?

svn checkout and install of the 6.4 release branch

you should run "make distclean" when ever you do a full "svn up".
Especially whenever something in the ./configure script or in include/
changes.

(gis.h in the stable branch just changed for the first time in 17 months)

Hamish

5

On Wed, Oct 6, 2010 at 6:39 PM, Hamish <hamish_b@yahoo.com> wrote:

Hamish:

> what was the exact error message?

Stephen:

ERROR: Incompatible library version for module. You need to rebuild GRASS
or untangle multiple installations

> how was it broken?

svn checkout and install of the 6.4 release branch

Hamish:

you should run "make distclean" when ever you do a full "svn up".
Especially whenever something in the ./configure script or in include/
changes.

(gis.h in the stable branch just changed for the first time in 17 months)

Hamish

Hamish I have written a script to dowload, configure, make, and
install grass for me. Should I make dist clean at the end of this
script in preparation for the next svn up, or should I put the make
distclean right before the make command in the script? Any advice
would be appreciated.

Stephen

--
Stephen Sefick
____________________________________
| Auburn University |
| Department of Biological Sciences |
| 331 Funchess Hall |
| Auburn, Alabama |
| 36849 |
|___________________________________|
| sas0025@auburn.edu |
| http://www.auburn.edu/~sas0025 |
|___________________________________|

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods. We are mammals, and have not exhausted the
annoying little problems of being mammals.

                            \-K\. Mullis

"A big computer, a complex algorithm and a long time does not equal science."

                          \-Robert Gentleman
6

Hiu,

2010/10/7 stephen sefick <ssefick@gmail.com>:

Hamish I have written a script to dowload, configure, make, and
install grass for me. Should I make dist clean at the end of this
script in preparation for the next svn up, or should I put the make
distclean right before the make command in the script? Any advice
would be appreciated.

make distclean
configure
make
make install

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

7

Martin Landa:

Hiu,

stephen sefick:

Hamish I have written a script to dowload, configure, make, and
install grass for me. Should I make dist clean at the end of this
script in preparation for the next svn up, or should I put the make
distclean right before the make command in the script? Any advice
would be appreciated.

The safest order I figured out experimentally is

make distclean

svn up

configure
make
make install

Markus M

8

Thank you all for your help.

Stephen

On Thu, Oct 7, 2010 at 3:06 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Martin Landa:

Hiu,

stephen sefick:

Hamish I have written a script to dowload, configure, make, and
install grass for me. Should I make dist clean at the end of this
script in preparation for the next svn up, or should I put the make
distclean right before the make command in the script? Any advice
would be appreciated.

The safest order I figured out experimentally is

make distclean

svn up

configure
make
make install

Markus M

--
Stephen Sefick
____________________________________
| Auburn University |
| Department of Biological Sciences |
| 331 Funchess Hall |
| Auburn, Alabama |
| 36849 |
|___________________________________|
| sas0025@auburn.edu |
| http://www.auburn.edu/~sas0025 |
|___________________________________|

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods. We are mammals, and have not exhausted the
annoying little problems of being mammals.

                            \-K\. Mullis

"A big computer, a complex algorithm and a long time does not equal science."

                          \-Robert Gentleman
9

On Thu, Oct 7, 2010 at 10:06 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Martin Landa:

Hiu,

stephen sefick:

Hamish I have written a script to dowload, configure, make, and
install grass for me. Should I make dist clean at the end of this
script in preparation for the next svn up, or should I put the make
distclean right before the make command in the script? Any advice
would be appreciated.

The safest order I figured out experimentally is

make distclean

svn up

configure
make
make install

Markus M

Added as FAQ:
http://grass.osgeo.org/wiki/Error_incompatible_library_version_for_module

Markus

10

Hi,

I have a truncation problem with v.db.join. This has been raised before -

([GRASS-user] Re: grass v.db.join

Gary Nobles
Fri, 12 Mar 2010 11:11:26 -0800)

- but I have not seen a solution. I have tried my own data, the
spearfish60 example data, and the example in Neteler and Mitasova's book.
The new data columns are apparently defined as 1 character long, and the
data become truncated accordingly, much against my intention. I use mysql.

Can anyone point out a solution? I copy a session with the spearfish60
data below.

Jon

GRASS 6.4.0 (spearfish60):~ > g.copy vect=soils,mysoils
Copy vector <soils@PERMANENT> to current mapset as <mysoils>
GRASS 6.4.0 (spearfish60):~ > db.select mysoils
cat|label
1|Aab
2|Ba
3|Bb
4|BcB
5|BcC
6|BeE
.
.
.
GRASS 6.4.0 (spearfish60):~ > db.in.ogr soils_legend.csv out=soils_legend
Imported table <soils_legend> with 55 rows
GRASS 6.4.0 (spearfish60):~ > db.select soils_legend
id|shortname|longname
0|no data|no data
1|AaB|Alice fine sandy loam, 0 to 6
2|Ba|Barnum silt loam
3|Bb|Barnum silt loam, channeled
4|BcB|Boneek silt loam, 2 to 6
5|BcC|Boneek silt loam, 6 to 9
6|BeE|Butche stony loam, 6 to 50
.
.
.
GRASS 6.4.0 (spearfish60):~ > v.db.join mysoils col=label
otable=soils_legend ocol=shortname
GRASS 6.4.0 (spearfish60):~ > v.db.select mysoils
cat|label|id|shortname|longname
1|Aab|1|A|A
2|Ba|2|B|B
3|Bb|3|B|B
4|BcB|4|B|B
5|BcC|5|B|B
6|BeE|6|B|B
.
.
.
GRASS 6.4.0 (spearfish60):~ > db.describe -c mysoils
ncols: 5
nrows: 54
Column 1: cat:INTEGER:11
Column 2: label:CHARACTER:13
Column 3: id:CHARACTER:1
Column 4: shortname:CHARACTER:1
Column 5: longname:CHARACTER:1
GRASS 6.4.0 (spearfish60):~ > db.describe -c soils_legend
ncols: 3
nrows: 55
Column 1: id:CHARACTER:255
Column 2: shortname:CHARACTER:255
Column 3: longname:CHARACTER:255
GRASS 6.4.0 (spearfish60):~ >

11

[...]

Markus M:

The safest order I figured out experimentally is

> make distclean

svn up

> configure
> make
> make install

- make install requires "sudo" under Ubuntu.

- a reminder that the last step ("sudo make install") can be avoided
completely and grass sessions can be launched directly from within the
"/geo/osgeo/src/grass64_release/bin.x86_64-unknown-linux-gnu/" directory.

e.g., I use the following link:

/usr/local/bin/grass64 -> /geo/osgeo/src/grass64_release/bin.x86_64-unknown-
linux-gnu/grass64

Also, in case one wants to install the compiled binaries, the program
"checkinstall" is a good option instead of "make install". It creates a .deb
package and installs it which can be easily uninstalled of course.

Cheers, Nikos

12

On Fri, Oct 8, 2010 at 12:56 PM, Jón Eiríksson <jeir@hi.is> wrote:

Hi,

I have a truncation problem with v.db.join. This has been raised before -

...

The new data columns are apparently defined as 1 character long, and the
data become truncated accordingly, much against my intention. I use mysql.

Can anyone point out a solution? I copy a session with the spearfish60
data below.

Jon

GRASS 6.4.0 (spearfish60):~ > g.copy vect=soils,mysoils
Copy vector <soils@PERMANENT> to current mapset as <mysoils>
GRASS 6.4.0 (spearfish60):~ > db.select mysoils
cat|label
1|Aab
2|Ba
3|Bb
4|BcB
5|BcC
6|BeE
.
.
.
GRASS 6.4.0 (spearfish60):~ > db.in.ogr soils_legend.csv out=soils_legend
Imported table <soils_legend> with 55 rows
GRASS 6.4.0 (spearfish60):~ > db.select soils_legend
id|shortname|longname
0|no data|no data
1|AaB|Alice fine sandy loam, 0 to 6
2|Ba|Barnum silt loam
3|Bb|Barnum silt loam, channeled
4|BcB|Boneek silt loam, 2 to 6
5|BcC|Boneek silt loam, 6 to 9
6|BeE|Butche stony loam, 6 to 50
.
.

...so far so nice...

could you please edit v.db.join and add a -x to the first line?
Find the script with
which v.db.join

So: before
#!/bin/sh

after:

#!/bin/sh -x

Then run v.db.join:

GRASS 6.4.0 (spearfish60):~ > v.db.join mysoils col=label
otable=soils_legend ocol=shortname

and check where the stuff is eaten. Please send relevant chunks (if long,
maybe better open a ticket at http://trac.osgeo.org/grass/ for this).

GRASS 6.4.0 (spearfish60):~ > v.db.select mysoils
cat|label|id|shortname|longname
1|Aab|1|A|A
2|Ba|2|B|B
3|Bb|3|B|B
4|BcB|4|B|B
5|BcC|5|B|B
6|BeE|6|B|B
.
.
.
GRASS 6.4.0 (spearfish60):~ > db.describe -c mysoils
ncols: 5
nrows: 54
Column 1: cat:INTEGER:11
Column 2: label:CHARACTER:13
Column 3: id:CHARACTER:1
Column 4: shortname:CHARACTER:1
Column 5: longname:CHARACTER:1
GRASS 6.4.0 (spearfish60):~ > db.describe -c soils_legend
ncols: 3
nrows: 55
Column 1: id:CHARACTER:255
Column 2: shortname:CHARACTER:255
Column 3: longname:CHARACTER:255

We need to understand what happens in v.db.join with mysql.

Markus