wingrass: include also unversioned libraries

[martinl]

Currently WinGRASS builds contain only versioned GRASS libs, eg. libgrass_gis.x.y.z.dll. This makes QGIS GRASS broken in OSGeo4W framework everytime when a new GRASS point version is released and QGIS GRASS plugin is still compiled against old point version. WinGRASS could contain also copy of unversioned libs to avoid such problem (creating symlinks as done on non-mingw platform cannot work here).

[martinl]

GRASS 7.7 (trunk) has been modified in r73864 to produce also unversioned libs on Windows. Can be tested with build no. 357+ from (1) or directly from OSGeo4W framework (grass-daily package).

(1) ​https://wingrass.fsv.cvut.cz/grass77/x86_64/

[martinl]

In 73865:

remove extra line in Shlib.make, see #3718

[martinl]

Result tested with GRASS 7.7svn.

[neteler]

May I release or is anything still open here?

[martinl]

Replying to neteler:

May I release or is anything still open here?

yes, still open.

[martinl]

See related discussion, ​https://lists.osgeo.org/pipermail/grass-dev/2018-December/090823.html

[hellik]

Replying to martinl:

See related discussion, ​https://lists.osgeo.org/pipermail/grass-dev/2018-December/090823.html

around 7 years ago there was a thread about versioned/unversioned dlls/libs in winGRASS, see

​https://lists.osgeo.org/pipermail/grass-dev/2010-June/050757.html

see mails before and after.

[hellik]

Replying to martinl:

See related discussion, ​https://lists.osgeo.org/pipermail/grass-dev/2018-December/090823.html

Is it acceptable solution? If so I will do backport to g76 a g74
branches ASAP.

what is the reason to backport it to g74?

QGIS 2.18.x reaches its EOL and AFAIU our focus will be on (7.6)/7.8.

it seems there will be a little chance that QGIS 2.18.x/g74 will change.

[martinl]

Replying to hellik:

it seems there will be a little chance that QGIS 2.18.x/g74 will change.

you are right, changing milestone

[martinl]

In 73905:

Shlib.make: MinGW's 'ln' just copies the file, see #3718

[martinl]

Replying to hellik:

see mails before and after.

my comment

> Should the ctypes wrappers be changed to use the versioned library
> name?

Probably yes, just to avoid having copy of unversioned library names.

sounds nice from GRASS POV. On the other hand would be nice not to break QGIS GRASS plugin on each GRASS point version ;-)

[hellik]

Replying to martinl:

Replying to hellik:

see mails before and after.

my comment

> Should the ctypes wrappers be changed to use the versioned library
> name?

Probably yes, just to avoid having copy of unversioned library names.

sounds nice from GRASS POV. On the other hand would be nice not to break QGIS GRASS plugin on each GRASS point version ;-)

it's more about

However: on Windows, the name used to create the DLL (e.g. 
libgrass_gis.7.0.svn.dll) is stored in the DLL, and this is preserved
when the file is copied. When linking against a DLL, the name which is
stored in the target (library or executable) is the name stored in the
library, not the name of the file. So linking with -lgrass_gis links
against libgrass_gis.dll, but the resulting executable or library
depends upon libgrass_gis.7.0.svn.dll.

[martinl]

ah, I see, reverted in r73921

[martinl]

Another option would be to remove at least point version from lib names, see related discussion at ​https://lists.osgeo.org/pipermail/grass-dev/2019-January/090920.html

[martinl]

Closing issue as wontfix, see #3728