[GRASS-dev] "Incompatible library version" errors

GRASS GRASS developer
,
1

This:
  http://trac.osgeo.org/grass/changeset/33327

- G_fatal_error(_("Incompatible library version for module"));
+ G_fatal_error(_("Incompatible library version for module: recompilation needed."));

isn't necessarily accurate.

The error could also be caused by a mismatch between PATH and
LD_LIBRARY_PATH (or ld.so.cache, etc) if you have more than one
version of GRASS installed.

Or it could be caused by a module linking against GDAL, where GDAL was
built against an old version of GRASS. In that case, it's true that
recompilation is needed, but it would be GDAL that needs
recompilation.

In general, error messages should only report what is known; they
shouldn't attempt to guess as the underlying cause.

E.g. if write() fails, then you know that write() failed. You don't
know that it was due to insufficient disk space unless errno is set to
ENOSPC. write() can also fail with EDQUOT (quota exceeded), EFBIG
(maximum size of a single file exceeded), EIO (low-level I/O error,
e.g. media fault, failed NFS server), and others.

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

2

Glynn, You are correct about this error message, still IMHO it's good
to provide most likely failure case and a hint what to do next/how to
fix it. I numerous times have stumbled on "cannot write" errors and
friendly hint to run df lots of times has saved a day :wink:

Maris.

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

In general, error messages should only report what is known; they
shouldn't attempt to guess as the underlying cause.

E.g. if write() fails, then you know that write() failed. You don't
know that it was due to insufficient disk space unless errno is set to
ENOSPC. write() can also fail with EDQUOT (quota exceeded), EFBIG
(maximum size of a single file exceeded), EIO (low-level I/O error,
e.g. media fault, failed NFS server), and others.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

On Tue, Sep 9, 2008 at 12:10 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

This:
       http://trac.osgeo.org/grass/changeset/33327

- G_fatal_error(_("Incompatible library version for module"));
+ G_fatal_error(_("Incompatible library version for module: recompilation needed."));

isn't necessarily accurate.

The error could also be caused by a mismatch between PATH and
LD_LIBRARY_PATH (or ld.so.cache, etc) if you have more than one
version of GRASS installed.

Or it could be caused by a module linking against GDAL, where GDAL was
built against an old version of GRASS. In that case, it's true that
recompilation is needed, but it would be GDAL that needs
recompilation.

In general, error messages should only report what is known; they
shouldn't attempt to guess as the underlying cause.

Ah, I wasn't aware of all those other possibilities.
I only found the original message too minimalistic.

E.g. if write() fails, then you know that write() failed. You don't
know that it was due to insufficient disk space unless errno is set to
ENOSPC. write() can also fail with EDQUOT (quota exceeded), EFBIG
(maximum size of a single file exceeded), EIO (low-level I/O error,
e.g. media fault, failed NFS server), and others.

Sure but in this case there are ENOSPC, EDQUOT etc. (so indications
could be trapped).

Anyway, I have reverted it.

Markus

4

Markus Neteler wrote:

> E.g. if write() fails, then you know that write() failed. You don't
> know that it was due to insufficient disk space unless errno is set to
> ENOSPC. write() can also fail with EDQUOT (quota exceeded), EFBIG
> (maximum size of a single file exceeded), EIO (low-level I/O error,
> e.g. media fault, failed NFS server), and others.

Sure but in this case there are ENOSPC, EDQUOT etc. (so indications
could be trapped).

That requires that either:

a) error messages are generated at the point that the error occurs,
which is problematic if you don't always want to report the error, or

b) errno is preserved until you get to the point that you do actually
want to report the error, which means saving and restoring it if you
need to perform any error recovery which involves calling functions
which might themselves set errno. This is particularly problematic if
the error occurs in a library function but the decision on whether to
report it is left to individual modules, as the effort required is
multiplied dramatically.

However, in cases where the library function reports the error via
G_fatal_error(), there are probably many cases where we could make use
of enhanced versions of G_fatal_error() (or even G_warning()) which
include strerror(errno) in the output.

Also, there are a lot of cases where the library functions leave it to
the caller to report the error, even though 99.9% of callers will just
call G_fatal_error() (e.g. G_open_*_{old,new}(), G_{get,put}_*_row()).
These should probably be replaced with wrappers which just call
G_fatal_error(), with the original functions being renamed to e.g.
G_open_cell_old_no_error() etc.

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