I am trying to find a way to inject GRASS modules (C code)
compiled in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:
ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
This is coming from 'libgrass_gis'.
Apparently, GRASS keeps exact timestamps of the binaries and
won't allow any mixing.
Is it really necessary to be this strict about build versions?
Would it be possible to relax this, so that a module compiled with
GRASS 7.8.a can be run under GRASS 7.8.b?
I worked around this issue with some LD_LIBRARY_PATH "magic",
and even running 7.8.1 binaries in a 7.8.5 installation seems
to work flawlessly.
Background: I am trying to find a way to provide sets of
additional modules, that are not part of the GRASS base
distribution, for injection into an existing GRASS installation.
This is exceedingly hard if all dependencies have to be
exact matches; especially if the modules are to be injected
into a version of GRASS bundled with QGIS.
On Fri, 05. Mar 2021 at 20:23:47 +0100, Benjamin Ducke wrote:
I am trying to find a way to inject GRASS modules (C code)
compiled in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:
ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
This is coming from 'libgrass_gis'.
Apparently, GRASS keeps exact timestamps of the binaries and
won't allow any mixing.
Note: In OSGeo4W testing I've disabled that check in lib/gis/gisinit.c. The
DLLs already carry the major and minor version number in their name already.
I guess it's there because the ABI could change anytime - even in point
releases - and the libs are only meant for GRASS itself AFAIK.
But I'd also think that the chance for breakages is reasonable small enough to
do this. Using the libs with a different compiler in the QGIS plugin like we
do is probably a bigger risk anyway.
Jürgena.
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden https://www.norbit.de
QGIS release manager (PSC) Germany IRC: jef on FreeNode
On Fri, 05. Mar 2021 at 20:23:47 +0100, Benjamin Ducke wrote:
I am trying to find a way to inject GRASS modules (C code)
compiled in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:
ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
This is coming from 'libgrass_gis'.
Apparently, GRASS keeps exact timestamps of the binaries and
won't allow any mixing.
Note: In OSGeo4W testing I've disabled that check in lib/gis/gisinit.c. The
DLLs already carry the major and minor version number in their name already.
Ha! I was at exactly that point, as well. Good to know that I
am not just imaging an obstacle here.
I guess it's there because the ABI could change anytime - even in point
releases - and the libs are only meant for GRASS itself AFAIK.
That is probably the reason. But as it stands, this strictness
even prevents mixing of binaries from the same point release,
if the modules were not compiled at the same time as the GRASS libs.
I would also expect the fundamental GRASS lib (libgrass_gis) to
be quite stable as far as the ABI is concerned. GRASS is a very
conservative design -- and has done extremely well by it over
the decades.
But I'd also think that the chance for breakages is reasonable small enough to
do this. Using the libs with a different compiler in the QGIS plugin like we
do is probably a bigger risk anyway.
Yes, that's another "mixing case" that I did not even
think about. C objects are so wonderfully simple and
flexible to link. Why not allow a little more freedom
here?
How about changing the behaviour of libgrass_gis to issue
a warning as along as the major and minor revisions match,
and an error only if that is not the case?
I am trying to find a way to inject GRASS modules (C code)
compiled in a GRASS 7 source tree into an already installed
version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
then copy into a GRASS 7.8.5 (i.e. exact version match)
installation, I get this:
ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
GRASS uses the git revision to check if separately compiled modules are compatible with the current version. If the git revision is not available, the date of compilation is used instead. This is a safety measure to ensure binary compatibility. The idea of using the date of compilation as surrogate is targeted at branches under development and might not be appropriate for released versions that do not change any more. Apparently we need to distinguish between released versions and versions under development and adjust the check for binary compatibility accordingly.
Markus M
This is coming from ‘libgrass_gis’.
Apparently, GRASS keeps exact timestamps of the binaries and
won’t allow any mixing.
Is it really necessary to be this strict about build versions?
Would it be possible to relax this, so that a module compiled with
GRASS 7.8.a can be run under GRASS 7.8.b?
I worked around this issue with some LD_LIBRARY_PATH “magic”,
and even running 7.8.1 binaries in a 7.8.5 installation seems
to work flawlessly.
Background: I am trying to find a way to provide sets of
additional modules, that are not part of the GRASS base
distribution, for injection into an existing GRASS installation.
This is exceedingly hard if all dependencies have to be
exact matches; especially if the modules are to be injected
into a version of GRASS bundled with QGIS.
On Fri, Mar 5, 2021 at 8:30 PM Benjamin Ducke <benducke@fastmail.fm <mailto:benducke@fastmail.fm>> wrote:
>
> Dear Devs,
>
> I am trying to find a way to inject GRASS modules (C code)
> compiled in a GRASS 7 source tree into an already installed
> version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
> then copy into a GRASS 7.8.5 (i.e. exact version match)
> installation, I get this:
>
> ERROR: Module built against version 2021-03-04T21:51:47+00:00 but trying to
> use version 2021-01-01T10:33:43+00:00. You need to rebuild GRASS GIS
> or untangle multiple installations.
GRASS uses the git revision to check if separately compiled modules are compatible with the current version. If the git revision is not available, the date of compilation is used instead. This is a safety measure to ensure binary compatibility. The idea of using the date of compilation as surrogate is targeted at branches under development and might not be appropriate for released versions that do not change any more. Apparently we need to distinguish between released versions and versions under development and adjust the check for binary compatibility accordingly.
Thanks for the explanation. This makes a lot of sense.
If it would be possible to somehow change the behaviour
of release version binaries in this regard, then I would
vote for checking against major, minor and revision
number at runtime, and:
1. Do nothing, if major, minor and revision of module and
GRASS libs are identical.
2. Warn, if revision numbers differ (but major and minor
are identical).
3. Throw an error, if major or minor versions differ.
This should result in acceptable and sage behaviour for
externally compiled modules.
Best,
Ben
Markus M
>
> This is coming from 'libgrass_gis'.
>
> Apparently, GRASS keeps exact timestamps of the binaries and
> won't allow any mixing.
>
> Is it really necessary to be this strict about build versions?
> Would it be possible to relax this, so that a module compiled with
> GRASS 7.8.a can be run under GRASS 7.8.b?
>
> I worked around this issue with some LD_LIBRARY_PATH "magic",
> and even running 7.8.1 binaries in a 7.8.5 installation seems
> to work flawlessly.
>
> Background: I am trying to find a way to provide sets of
> additional modules, that are not part of the GRASS base
> distribution, for injection into an existing GRASS installation.
> This is exceedingly hard if all dependencies have to be
> exact matches; especially if the modules are to be injected
> into a version of GRASS bundled with QGIS.
>
> Best,
>
> Ben
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/grass-dev