In the new trunk GRASS 7.1, I’m running into an error check like the following:
GRASS 7.1.svn (Penaguila):~ > r.flip &
[1] 76586
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple installations.
[1]+ Exit 1 r.flip
There is some value to this, but it may create more problems than it solves. As a test of what is happening to missing addons path, I installed from the GRASS 7 extensions library the module r.flip. While it is possible that r.flip will not work with revision 62364, many modules built for other revisions of the same GRASS version WILL work with a newer version. This is especially true with a lot of development work going on.
A binary module is almost guaranteed to be built with a revision that predates the current one. Perhaps a warning is warranted but to prevent this from running seems extreme.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
2014-11-26 19:32 GMT+01:00 Michael Barton <Michael.Barton@asu.edu>:
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple installations.
Will this be the case for all extensions built against a revision of current - 1?
If so, then there is no point in installing any binary module.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Nov 26, 2014, at 11:51 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2014-11-26 19:32 GMT+01:00 Michael Barton <Michael.Barton@asu.edu>:
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple installations.
Will this be the case for all extensions built against a revision of current - 1?
Today yes, due to an API change in libgis.
If so, then there is no point in installing any binary module.
Why?
As soon as G7 is stable these changes will unlikely or at least only very rarely occur.
Markus
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple installations.
For any version of GRASS for which there is any reasonable development, all binary extensions will be out of date as soon as the first update is made. So they all will need to be recompiled. Why do we need to do this? Most will work fine without recompiling.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Will this be the case for all extensions built against a revision of current - 1?
Today yes, due to an API change in libgis.
If so, then there is no point in installing any binary module.
Why?
As soon as G7 is stable these changes will unlikely or at least only very rarely occur.
Markus
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
ERROR: Module built against version $Revision: 61095 $ but trying to use
version $Revision: 62364 $. You need to rebuild GRASS GIS or
untangle multiple installations.
Because getting developers to agree to maintaining a stable ABI (then
ensuring that actually happens) appears to be beyond our capabilities.
Probably the most common (and certainly the most obvious) example of
incompatible changes (and the trigger for adding that check in the
first place) is adding new enumerants in the middle of "enum STD_OPT"
(the constants passed to G_define_standard_option()), resulting in all
subsequent enumerants getting new values, resulting in the module
suddenly accepting completely different (and usually completely
nonsensical) options.
On Wed, Nov 26, 2014 at 2:13 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:
Why do we need to do this?
From my experience it it good to have it. The risk of getting some cryptic
errors is pretty high. This will tell you exactly what's happening before
anything cryptic actually happens. Unfortunately, I don't have any example
at hand but it seems better that we have this early waring system which
might be wrong sometimes rather then being surprised and puzzled in other
cases ("better safe than sorry").
Markus explained that this is for libgis only. That seems OK to me. My concern (based on the error message generated) is that this would block any module built against any version older than the current one being run. That seemed an unnecessarily strong check, but apparently not what is happening.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Nov 27, 2014, at 10:40 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Why do we need to do this?
Because getting developers to agree to maintaining a stable ABI (then
ensuring that actually happens) appears to be beyond our capabilities.
Probably the most common (and certainly the most obvious) example of
incompatible changes (and the trigger for adding that check in the
first place) is adding new enumerants in the middle of "enum STD_OPT"
(the constants passed to G_define_standard_option()), resulting in all
subsequent enumerants getting new values, resulting in the module
suddenly accepting completely different (and usually completely
nonsensical) options.
On Fri, Nov 28, 2014 at 11:25 PM, Michael Barton <Michael.Barton@asu.edu> wrote:
Markus explained that this is for libgis only. That seems OK to me. My concern (based on the error message generated) is that this would block any module built against any version older than the current one being run. That seemed an unnecessarily strong check, but apparently not what is happening.
Actually this should happen for modules. If libgis or any other lib
changes in trunk, all modules using libgis and/or the respective lib
need to be recompiled. There is no reason to assume that different
revisions of trunk are binary compatible, it's trunk.
Markus M
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Nov 27, 2014, at 10:40 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Why do we need to do this?
Because getting developers to agree to maintaining a stable ABI (then
ensuring that actually happens) appears to be beyond our capabilities.
Probably the most common (and certainly the most obvious) example of
incompatible changes (and the trigger for adding that check in the
first place) is adding new enumerants in the middle of "enum STD_OPT"
(the constants passed to G_define_standard_option()), resulting in all
subsequent enumerants getting new values, resulting in the module
suddenly accepting completely different (and usually completely
nonsensical) options.
> Markus explained that this is for libgis only. That seems OK to
> me. My concern (based on the error message generated) is that this
> would block any module built against any version older than the
> current one being run. That seemed an unnecessarily strong check,
> but apparently not what is happening.
Actually this should happen for modules. If libgis or any other lib
changes in trunk, all modules using libgis and/or the respective lib
need to be recompiled. There is no reason to assume that different
revisions of trunk are binary compatible, it's trunk.
Indeed. The only reason it hasn't been done for other libraries is
that there haven't been sufficient issues to warrant the effort.
Ideally, each library would contain the actual revision number as part
of the name (so libgrass_gis.7.1.svn.so would actually be e.g.
libgrass_gis.63308.svn.so).
Unfortunately, getting the correct version number isn't
straightforward.
We can't just use "svn info" on the source directory because
1. Many of the ABI-breaking changes are in header files rather than
the library.
2. Not everyone gets their source tree from SVN; tarballs don't have
the .svn directory and "svn info" won't work there.
OTOH, using a revision from a single header isn't particularly robust
either. It just happens to work for the most common single source of
ABI incompatibilities.
just for the record, by chance it happened to me today and how I
solved it easily:
GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
stream_rast=streams@user1 direction=direction@user1
elevation=elevation@PERMANENT accumulation=accum@user1
stream_vect=streams horton=horton
ERROR: Module built against version $Revision: 62395 $ but trying to use
version $Revision: 63222 $. You need to rebuild GRASS GIS or
untangle multiple installations.
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
On Dec 2, 2014, at 1:37 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi,
just for the record, by chance it happened to me today and how I
solved it easily:
GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
stream_rast=streams@user1 direction=direction@user1
elevation=elevation@PERMANENT accumulation=accum@user1
stream_vect=streams horton=horton
ERROR: Module built against version $Revision: 62395 $ but trying to use
version $Revision: 63222 $. You need to rebuild GRASS GIS or
untangle multiple installations.