[GRASS-dev] GRASS module version strictness (libgrass_gis)

Benjamin Ducke benducke at fastmail.fm
Fri Mar 5 13:14:13 PST 2021


Hi,

On 05/03/2021 21:14, Jürgen E. Fischer wrote:
> Hi,
> 
> 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?

Best,

Ben

> 
> 
> Jürgena.
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 



More information about the grass-dev mailing list