Dear Markus:
On 12/03/2021 22:35, Markus Metz wrote:
On Fri, Mar 5, 2021 at 8:30 PM Benjamin Ducke <bendu...@fastmail.fm
<mailto:bendu...@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
<https://lists.osgeo.org/mailman/listinfo/grass-dev>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
