[GRASS-user] grass6.4 develbrunch revision 32726: undefined reference to `G_no_gisinit'

GRASS GRASS user
1

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

It appears for many binaries (various vector, raster and others commands).

I also receive tens of warnings, but it's secondary...

2008/8/12 Michael Barton <michael.barton@asu.edu>:

Let me know if this solves the issue.

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

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

On Aug 12, 2008, at 9:14 AM, G. Allegri wrote:

Anyway, as Michel has noted from my #254 ticket, I hadn't switch to
develbranch_6 yet, so I was trying to compile grass 7 (in trunk). In
fact I was receiving tons of errors... :slight_smile:
I'm doing a brand new checkout from develbranch_6 right now.

2008/8/12 Michael Barton <michael.barton@asu.edu>:

My understanding is that if you do a make distclean, you do not need to
do a
make clean too.

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

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

On Aug 12, 2008, at 9:02 AM, Nikos Alexandris wrote:

On Tue, 2008-08-12 at 08:45 -0700, Michael Barton wrote:

On Aug 12, 2008, at 2:23 AM, <grass-user-request@lists.osgeo.org>
wrote:

Date: Tue, 12 Aug 2008 11:21:19 +0200
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-user] grass6.4.svn revision32686: failed to
     compile r.terraflow and nviz2
To: "G. Allegri" <giohappy@gmail.com>
Cc: grassuser <grass-user@lists.osgeo.org>
Message-ID:
     <f8fe65c40808120221o21b8ce0ax5d816981a5a358c3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2008/8/12 G. Allegri <giohappy@gmail.com>:

neither r.terraflow nor nviz2.

From the error log, it seems to me that nviz library name is missing,

re-run configure script to fix it.

Martin

Maybe do a make clean or make distclean before compiling.

I always thought both are necessary (?) after a configuration and a
"make".

make clean --> cleans "make"d files
make distclean --> cleans configuration files

Is that correct?

Nikos

[...]

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

2

It looks from this snippit that there is some kind of problem with your gdal installation. Did you do a clean checkout from the svn of develbranch_6?

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

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

On Aug 12, 2008, at 9:30 AM, G. Allegri wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

It appears for many binaries (various vector, raster and others commands).

I also receive tens of warnings, but it's secondary...

2008/8/12 Michael Barton <michael.barton@asu.edu>:

Let me know if this solves the issue.

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

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

On Aug 12, 2008, at 9:14 AM, G. Allegri wrote:

Anyway, as Michel has noted from my #254 ticket, I hadn't switch to
develbranch_6 yet, so I was trying to compile grass 7 (in trunk). In
fact I was receiving tons of errors... :slight_smile:
I'm doing a brand new checkout from develbranch_6 right now.

2008/8/12 Michael Barton <michael.barton@asu.edu>:

My understanding is that if you do a make distclean, you do not need to
do a
make clean too.

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

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

On Aug 12, 2008, at 9:02 AM, Nikos Alexandris wrote:

On Tue, 2008-08-12 at 08:45 -0700, Michael Barton wrote:

On Aug 12, 2008, at 2:23 AM, <grass-user-request@lists.osgeo.org>
wrote:

Date: Tue, 12 Aug 2008 11:21:19 +0200
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-user] grass6.4.svn revision32686: failed to
    compile r.terraflow and nviz2
To: "G. Allegri" <giohappy@gmail.com>
Cc: grassuser <grass-user@lists.osgeo.org>
Message-ID:
    <f8fe65c40808120221o21b8ce0ax5d816981a5a358c3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2008/8/12 G. Allegri <giohappy@gmail.com>:

neither r.terraflow nor nviz2.

From the error log, it seems to me that nviz library name is missing,

re-run configure script to fix it.

Martin

Maybe do a make clean or make distclean before compiling.

I always thought both are necessary (?) after a configuration and a
"make".

make clean --> cleans "make"d files
make distclean --> cleans configuration files

Is that correct?

Nikos

[...]

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

3

Hi,

make distclean
svn up
./configure
make

should solve your problems...

Martin

2008/8/12 G. Allegri <giohappy@gmail.com>:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

It appears for many binaries (various vector, raster and others commands).

I also receive tens of warnings, but it's secondary...

2008/8/12 Michael Barton <michael.barton@asu.edu>:

Let me know if this solves the issue.

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

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

On Aug 12, 2008, at 9:14 AM, G. Allegri wrote:

Anyway, as Michel has noted from my #254 ticket, I hadn't switch to
develbranch_6 yet, so I was trying to compile grass 7 (in trunk). In
fact I was receiving tons of errors... :slight_smile:
I'm doing a brand new checkout from develbranch_6 right now.

2008/8/12 Michael Barton <michael.barton@asu.edu>:

My understanding is that if you do a make distclean, you do not need to
do a
make clean too.

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

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

On Aug 12, 2008, at 9:02 AM, Nikos Alexandris wrote:

On Tue, 2008-08-12 at 08:45 -0700, Michael Barton wrote:

On Aug 12, 2008, at 2:23 AM, <grass-user-request@lists.osgeo.org>
wrote:

Date: Tue, 12 Aug 2008 11:21:19 +0200
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-user] grass6.4.svn revision32686: failed to
     compile r.terraflow and nviz2
To: "G. Allegri" <giohappy@gmail.com>
Cc: grassuser <grass-user@lists.osgeo.org>
Message-ID:
     <f8fe65c40808120221o21b8ce0ax5d816981a5a358c3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2008/8/12 G. Allegri <giohappy@gmail.com>:

neither r.terraflow nor nviz2.

From the error log, it seems to me that nviz library name is missing,

re-run configure script to fix it.

Martin

Maybe do a make clean or make distclean before compiling.

I always thought both are necessary (?) after a configuration and a
"make".

make clean --> cleans "make"d files
make distclean --> cleans configuration files

Is that correct?

Nikos

[...]

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

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

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

4

Sorry,

try to rebuild also gdal, etc...

Martin

2008/8/12 Martin Landa <landa.martin@gmail.com>:

Hi,

make distclean
svn up
./configure
make

should solve your problems...

Martin

2008/8/12 G. Allegri <giohappy@gmail.com>:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

It appears for many binaries (various vector, raster and others commands).

I also receive tens of warnings, but it's secondary...

2008/8/12 Michael Barton <michael.barton@asu.edu>:

Let me know if this solves the issue.

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

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

On Aug 12, 2008, at 9:14 AM, G. Allegri wrote:

Anyway, as Michel has noted from my #254 ticket, I hadn't switch to
develbranch_6 yet, so I was trying to compile grass 7 (in trunk). In
fact I was receiving tons of errors... :slight_smile:
I'm doing a brand new checkout from develbranch_6 right now.

2008/8/12 Michael Barton <michael.barton@asu.edu>:

My understanding is that if you do a make distclean, you do not need to
do a
make clean too.

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

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

On Aug 12, 2008, at 9:02 AM, Nikos Alexandris wrote:

On Tue, 2008-08-12 at 08:45 -0700, Michael Barton wrote:

On Aug 12, 2008, at 2:23 AM, <grass-user-request@lists.osgeo.org>
wrote:

Date: Tue, 12 Aug 2008 11:21:19 +0200
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-user] grass6.4.svn revision32686: failed to
     compile r.terraflow and nviz2
To: "G. Allegri" <giohappy@gmail.com>
Cc: grassuser <grass-user@lists.osgeo.org>
Message-ID:
     <f8fe65c40808120221o21b8ce0ax5d816981a5a358c3@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

2008/8/12 G. Allegri <giohappy@gmail.com>:

neither r.terraflow nor nviz2.

From the error log, it seems to me that nviz library name is missing,

re-run configure script to fix it.

Martin

Maybe do a make clean or make distclean before compiling.

I always thought both are necessary (?) after a configuration and a
"make".

make clean --> cleans "make"d files
make distclean --> cleans configuration files

Is that correct?

Nikos

[...]

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

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

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

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

5

On Tue, Aug 12, 2008 at 6:30 PM, G. Allegri <giohappy@gmail.com> wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

You need to recompile the GRASS plugin, too.
Also QGIS, if you use. And the GRASS-R interface...
Essentially everything, which uses the GRASS libraries.

(we backported to 6.4.svn a method to avoid that outdated GRASS
libs are picked up, this AFAIK requires a recompilation of the depending
libraries and programs).

Markus

6

On Aug 12, 2008, at 11:06 AM, Markus Neteler wrote:

On Tue, Aug 12, 2008 at 6:30 PM, G. Allegri <giohappy@gmail.com> wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

You need to recompile the GRASS plugin, too.
Also QGIS, if you use. And the GRASS-R interface...
Essentially everything, which uses the GRASS libraries.

(we backported to 6.4.svn a method to avoid that outdated GRASS
libs are picked up, this AFAIK requires a recompilation of the depending
libraries and programs).

Does this require all new frameworks on the Mac?

Michael

7

Thanks for the tips. Just a question: why gdal recompiling is needed?
Is the version changed?

2008/8/12 Michael Barton <michael.barton@asu.edu>:

On Aug 12, 2008, at 11:06 AM, Markus Neteler wrote:

On Tue, Aug 12, 2008 at 6:30 PM, G. Allegri <giohappy@gmail.com> wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

You need to recompile the GRASS plugin, too.
Also QGIS, if you use. And the GRASS-R interface...
Essentially everything, which uses the GRASS libraries.

(we backported to 6.4.svn a method to avoid that outdated GRASS
libs are picked up, this AFAIK requires a recompilation of the depending
libraries and programs).

Does this require all new frameworks on the Mac?

Michael

8

On Aug 13, 2008, at 12:30 PM, G. Allegri wrote:

Thanks for the tips. Just a question: why gdal recompiling is needed?
Is the version changed?

2008/8/12 Michael Barton <michael.barton@asu.edu>:

On Aug 12, 2008, at 11:06 AM, Markus Neteler wrote:

On Tue, Aug 12, 2008 at 6:30 PM, G. Allegri <giohappy@gmail.com> wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

You need to recompile the GRASS plugin, too.
Also QGIS, if you use. And the GRASS-R interface...
Essentially everything, which uses the GRASS libraries.

(we backported to 6.4.svn a method to avoid that outdated GRASS
libs are picked up, this AFAIK requires a recompilation of the depending
libraries and programs).

Does this require all new frameworks on the Mac?

The necessity for rebuilding I think means if you want your binaries to use a newer GRASS 6.4.

Software on OSX has library paths and versions hardwired, so there is less chance of breaking something with a different version. ie, Qgis built with GRASS 6.3 support will continue to use GRASS 6.3, even if GRASS 6.4 is installed (the GRASS app keeps versions as separate app packages).

But if you had previously built Qgis for GRASS 6.4, then updated GRASS 6.4 which now includes this new versioning method, THEN you'll need to rebuild Qgis (or GRASS GDAL plugin or R extension).

Note: for my GDAL framework and Qgis, they use GRASS 6.3, so no updating of those is needed, but you do need to keep GRASS 6.3 installed.

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

I understand that everything that needs GRASS has to be recompiled if
this version changes so much to change its interface (QGis-GRASS
plugin, GRASS-GDAL plugin, etc.). But I would like to know why the new
develbrunch_6 revision needs the GDAL itself to be recompiled. I can
understand it if GRASS would need a newer version of GDAL... is this
the case?
Just to note: everything compiled ok from me until the trunk evision
of a week ago.

It's just curiosity. Tomorrow I will start compiling...

2008/8/13 William Kyngesburye <woklist@kyngchaos.com>:

On Aug 13, 2008, at 12:30 PM, G. Allegri wrote:

Thanks for the tips. Just a question: why gdal recompiling is needed?
Is the version changed?

2008/8/12 Michael Barton <michael.barton@asu.edu>:

On Aug 12, 2008, at 11:06 AM, Markus Neteler wrote:

On Tue, Aug 12, 2008 at 6:30 PM, G. Allegri <giohappy@gmail.com> wrote:

Noway.
Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

You need to recompile the GRASS plugin, too.
Also QGIS, if you use. And the GRASS-R interface...
Essentially everything, which uses the GRASS libraries.

(we backported to 6.4.svn a method to avoid that outdated GRASS
libs are picked up, this AFAIK requires a recompilation of the depending
libraries and programs).

Does this require all new frameworks on the Mac?

The necessity for rebuilding I think means if you want your binaries to use
a newer GRASS 6.4.

Software on OSX has library paths and versions hardwired, so there is less
chance of breaking something with a different version. ie, Qgis built with
GRASS 6.3 support will continue to use GRASS 6.3, even if GRASS 6.4 is
installed (the GRASS app keeps versions as separate app packages).

But if you had previously built Qgis for GRASS 6.4, then updated GRASS 6.4
which now includes this new versioning method, THEN you'll need to rebuild
Qgis (or GRASS GDAL plugin or R extension).

Note: for my GDAL framework and Qgis, they use GRASS 6.3, so no updating of
those is needed, but you do need to keep GRASS 6.3 installed.

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

10

Hi,

2008/8/13 G. Allegri <giohappy@gmail.com>:

[...]

develbrunch_6 revision needs the GDAL itself to be recompiled. I can
understand it if GRASS would need a newer version of GDAL... is this

my guess, if you have GDAL with GRASS support, you need also recompile GDAL.

Martin

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

11

G. Allegri wrote:

I understand that everything that needs GRASS has to be recompiled if
this version changes so much to change its interface (QGis-GRASS
plugin, GRASS-GDAL plugin, etc.). But I would like to know why the new
develbrunch_6 revision needs the GDAL itself to be recompiled. I can
understand it if GRASS would need a newer version of GDAL... is this
the case?

You only need to re-compile GDAL itself if GDAL was built with GRASS
support (--with-grass).

In your original message, you wrote:

Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

This indicates that your GDAL library was indeed built --with-grass. I
suggest building it without that option, and using the GDAL-GRASS
plugin instead.

If you build GDAL -with-grass, you will need to re-compile GDAL every
time that GRASS is updated from now on. The problem arises from
r32695, which makes G_gisinit() check that libgis was built with the
same version of gis.h as the caller.

The change adds G_gisinit() and G_no_gisinit() macros:

  #define GIS_H_VERSION "$Revision: 32726 $"

  #define G_gisinit(pgm) G__gisinit(GIS_H_VERSION, (pgm))
  #define G_no_gisinit() G__no_gisinit(GIS_H_VERSION)

The value of GIS_H_VERSION is automatically updated to the SVN
revision whenever gis.h is updated.

The change also renames the functions to G__gisinit() and
G__no_gisinit() (which is why you get the "undefined reference" error
when using an old GDAL with a new libgis), and adds version checks:

  int G__gisinit(const char *version, const char *pgm)
  {
      ...
      if (strcmp(version, GIS_H_VERSION) != 0)
    G_fatal_error(_("Incompatible library version for module"));

Any code which uses G_gisinit() or G_no_gisinit() passes the version
of gis.h with which it was compiled to the library functions, which
check that the same version of gis.h was used to compile the library.

The rationale is to avoid having to track down subtle errors caused by
version incompatibilities between libgis and any code which uses it.
Now, if there is an incompatibility, you get a very unsubtle error
telling you that there's an incompatibility.

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

12

Thanks Glynn, excellent explanation!
I didn't know that such a backward check on library version could be
done... my ignorance :slight_smile:

So, you suggest to avoid gdal --with-grass. What if I need to access
grass datas from outside grass, like with gdal/ogr utilities?

2008/8/14 Glynn Clements <glynn@gclements.plus.com>:

G. Allegri wrote:

I understand that everything that needs GRASS has to be recompiled if
this version changes so much to change its interface (QGis-GRASS
plugin, GRASS-GDAL plugin, etc.). But I would like to know why the new
develbrunch_6 revision needs the GDAL itself to be recompiled. I can
understand it if GRASS would need a newer version of GDAL... is this
the case?

You only need to re-compile GDAL itself if GDAL was built with GRASS
support (--with-grass).

In your original message, you wrote:

Even switching to develbrunch I receive the same error:
usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

This indicates that your GDAL library was indeed built --with-grass. I
suggest building it without that option, and using the GDAL-GRASS
plugin instead.

If you build GDAL -with-grass, you will need to re-compile GDAL every
time that GRASS is updated from now on. The problem arises from
r32695, which makes G_gisinit() check that libgis was built with the
same version of gis.h as the caller.

The change adds G_gisinit() and G_no_gisinit() macros:

       #define GIS_H_VERSION "$Revision: 32726 $"

       #define G_gisinit(pgm) G__gisinit(GIS_H_VERSION, (pgm))
       #define G_no_gisinit() G__no_gisinit(GIS_H_VERSION)

The value of GIS_H_VERSION is automatically updated to the SVN
revision whenever gis.h is updated.

The change also renames the functions to G__gisinit() and
G__no_gisinit() (which is why you get the "undefined reference" error
when using an old GDAL with a new libgis), and adds version checks:

       int G__gisinit(const char *version, const char *pgm)
       {
           ...
           if (strcmp(version, GIS_H_VERSION) != 0)
               G_fatal_error(_("Incompatible library version for module"));

Any code which uses G_gisinit() or G_no_gisinit() passes the version
of gis.h with which it was compiled to the library functions, which
check that the same version of gis.h was used to compile the library.

The rationale is to avoid having to track down subtle errors caused by
version incompatibilities between libgis and any code which uses it.
Now, if there is an incompatibility, you get a very unsubtle error
telling you that there's an incompatibility.

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

13

On Thu, 2008-08-14 at 05:37 +0100, Glynn Clements wrote:

G. Allegri wrote:

> I understand that everything that needs GRASS has to be recompiled if
> this version changes so much to change its interface (QGis-GRASS
> plugin, GRASS-GDAL plugin, etc.). But I would like to know why the new
> develbrunch_6 revision needs the GDAL itself to be recompiled. I can
> understand it if GRASS would need a newer version of GDAL... is this
> the case?

You only need to re-compile GDAL itself if GDAL was built with GRASS
support (--with-grass).

In your original message, you wrote:

> Even switching to develbrunch I receive the same error:
> usr/local/lib/libgdal.so: undefined reference to `G_no_gisinit'

This indicates that your GDAL library was indeed built --with-grass. I
suggest building it without that option, and using the GDAL-GRASS
plugin instead.

If you build GDAL -with-grass, you will need to re-compile GDAL every
time that GRASS is updated from now on. The problem arises from
r32695, which makes G_gisinit() check that libgis was built with the
same version of gis.h as the caller.

The change adds G_gisinit() and G_no_gisinit() macros:

  #define GIS_H_VERSION "$Revision: 32726 $"

  #define G_gisinit(pgm) G__gisinit(GIS_H_VERSION, (pgm))
  #define G_no_gisinit() G__no_gisinit(GIS_H_VERSION)

The value of GIS_H_VERSION is automatically updated to the SVN
revision whenever gis.h is updated.

The change also renames the functions to G__gisinit() and
G__no_gisinit() (which is why you get the "undefined reference" error
when using an old GDAL with a new libgis), and adds version checks:

  int G__gisinit(const char *version, const char *pgm)
  {
      ...
      if (strcmp(version, GIS_H_VERSION) != 0)
    G_fatal_error(_("Incompatible library version for module"));

Any code which uses G_gisinit() or G_no_gisinit() passes the version
of gis.h with which it was compiled to the library functions, which
check that the same version of gis.h was used to compile the library.

The rationale is to avoid having to track down subtle errors caused by
version incompatibilities between libgis and any code which uses it.
Now, if there is an incompatibility, you get a very unsubtle error
telling you that there's an incompatibility.

Funny! Today I recompiled all osgeo packages on my Ubuntu-box (install
proj4, install geos, compile gdal_stable without GRASS support, compile
GRASS6.4.svn, compile gdal-grass-plugin, compile qgis_0_11_0). I
carefully linked properly to the "local" installed libraries while
configuring QGIS with ccmake.

Now, while I run QGIS from within GRASS and use GRASS tools without
problems, I can't even load the GRASS-plugin if I run QGIS outside of
the GRASS-shell.

The error message is:
qgis: symbol lookup error: /usr/local/lib/libqgisgrass.so.1.0: undefined
symbol: G__no_gisinit

Greetings, Nikos

14

G. Allegri wrote:

I didn't know that such a backward check on library version could be
done... my ignorance :slight_smile:

So, you suggest to avoid gdal --with-grass. What if I need to access
grass datas from outside grass, like with gdal/ogr utilities?

Use the GDAL-GRASS plug-in. Then, you only need to re-compile the
plug-in whenever you update GRASS.

Alternatively:

Build and install GRASS 6.3. Build GDAL --with-grass, and install it.
Use this for QGIS, GDAL utilities, etc.

Build GDAL again --without-grass and install it somewhere it won't
normally be found (i.e. not in /usr or /usr/local).

If you want to use an updated version of GRASS, build it against the
GRASS-less GDAL and run it in place.

Even without this specific issue, building GDAL --with-grass is
problematic as GRASS depends quite heavily upon GDAL, so having a
version of GDAL which depends upon GRASS creates a circular
dependency.

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

15

perfect. I was used to build grass, then build gdal with grass, and
then rebuild grass. This time I'll follow your suggestion:
I've just built gdal 1.5.2 (without grass) and grass (--with-gdal) ,
and now I will compile gdal-grass plugin 1.4.2.

Last question (I'm sorry for my ignorance!): why grass configure asks
for --with-gdal? Does this option prepare grass to use the gdal-grass
plugin?

2008/8/14 Glynn Clements <glynn@gclements.plus.com>:

G. Allegri wrote:

I didn't know that such a backward check on library version could be
done... my ignorance :slight_smile:

So, you suggest to avoid gdal --with-grass. What if I need to access
grass datas from outside grass, like with gdal/ogr utilities?

Use the GDAL-GRASS plug-in. Then, you only need to re-compile the
plug-in whenever you update GRASS.

Alternatively:

Build and install GRASS 6.3. Build GDAL --with-grass, and install it.
Use this for QGIS, GDAL utilities, etc.

Build GDAL again --without-grass and install it somewhere it won't
normally be found (i.e. not in /usr or /usr/local).

If you want to use an updated version of GRASS, build it against the
GRASS-less GDAL and run it in place.

Even without this specific issue, building GDAL --with-grass is
problematic as GRASS depends quite heavily upon GDAL, so having a
version of GDAL which depends upon GRASS creates a circular
dependency.

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

16

Nikos Alexandris wrote:

Funny! Today I recompiled all osgeo packages on my Ubuntu-box (install
proj4, install geos, compile gdal_stable without GRASS support, compile
GRASS6.4.svn, compile gdal-grass-plugin, compile qgis_0_11_0). I
carefully linked properly to the "local" installed libraries while
configuring QGIS with ccmake.

Now, while I run QGIS from within GRASS and use GRASS tools without
problems, I can't even load the GRASS-plugin if I run QGIS outside of
the GRASS-shell.

The error message is:
qgis: symbol lookup error: /usr/local/lib/libqgisgrass.so.1.0: undefined
symbol: G__no_gisinit

QGIS is built for the new library but is loading an old version of the
library at run time.

When you start a GRASS session with the grass64 (etc) script, it sets
LD_LIBRARY_PATH to include $GISBASE/lib. Outside of a GRASS session,
it will use the normal LD_LIBRARY_PATH setting and /etc/ld.so.cache.

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

17

G. Allegri wrote:

perfect. I was used to build grass, then build gdal with grass, and
then rebuild grass. This time I'll follow your suggestion:
I've just built gdal 1.5.2 (without grass) and grass (--with-gdal) ,
and now I will compile gdal-grass plugin 1.4.2.

Last question (I'm sorry for my ignorance!): why grass configure asks
for --with-gdal? Does this option prepare grass to use the gdal-grass
plugin?

GRASS needs GDAL.

The --with-gdal switch allows the path to the gdal-config script to be
passed as an argument, in case it isn't in the path, or in case you
want to use a version other than the one which comes first in the
path. You can't use --without-gdal or --with-gdal=no; GDAL is
non-optional.

However, GRASS doesn't require that GDAL is built with GRASS support,
or the GDAL-GRASS plugin.

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

18

I was just writing again… answering to my (stupid) question by myself.
I was getting lost between GDAL and GRASS! :slight_smile:
Thanks anyway.

2008/8/14 Glynn Clements <glynn@gclements.plus.com>

G. Allegri wrote:

perfect. I was used to build grass, then build gdal with grass, and
then rebuild grass. This time I’ll follow your suggestion:
I’ve just built gdal 1.5.2 (without grass) and grass (–with-gdal) ,
and now I will compile gdal-grass plugin 1.4.2.

Last question (I’m sorry for my ignorance!): why grass configure asks
for --with-gdal? Does this option prepare grass to use the gdal-grass
plugin?

GRASS needs GDAL.

The --with-gdal switch allows the path to the gdal-config script to be
passed as an argument, in case it isn’t in the path, or in case you
want to use a version other than the one which comes first in the
path. You can’t use --without-gdal or --with-gdal=no; GDAL is
non-optional.

However, GRASS doesn’t require that GDAL is built with GRASS support,
or the GDAL-GRASS plugin.

–

Glynn Clements <glynn@gclements.plus.com>