landam / grass-gis-git-migration-test

0 stars 0 forks source link

wingrass: include also unversioned libraries #233

Open landam opened 5 years ago

landam commented 5 years ago

Reported by @landam on 26 Dec 2018 18:01 UTC 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).

Operating system

MS Windows

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/3718

landam commented 5 years ago

Attachment from @landam on 29 Dec 2018 15:30 UTC

https://trac.osgeo.org/grass/attachment/ticket/3718/unversioned-libs.png

landam commented 5 years ago

Modified by @landam on 26 Dec 2018 18:01 UTC

landam commented 5 years ago

Comment by @landam on 26 Dec 2018 18:05 UTC GRASS 7.7 (trunk) has been modified in https://trac.osgeo.org/grass/changeset/73864 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/

landam commented 5 years ago

Comment by @landam on 26 Dec 2018 18:06 UTC In [changeset:"73865\"] https://trac.osgeo.org/grass/changeset/73865:

remove extra line in Shlib.make, see #1
landam commented 5 years ago

Comment by @landam on 29 Dec 2018 15:31 UTC Result tested with GRASS 7.7svn.

https://trac.osgeo.org/grass/raw-attachment/ticket/3718/unversioned-libs.png, 400px

landam commented 5 years ago

Comment by neteler on 1 Jan 2019 18:33 UTC May I release or is anything still open here?

landam commented 5 years ago

Comment by @landam on 1 Jan 2019 19:24 UTC Replying to [comment:5 neteler]:

May I release or is anything still open here?

yes, still open.

landam commented 5 years ago

Comment by @landam on 1 Jan 2019 19:26 UTC See related discussion, https://lists.osgeo.org/pipermail/grass-dev/2018-December/090823.html

landam commented 5 years ago

Comment by hellik on 1 Jan 2019 19:54 UTC Replying to [comment:7 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.

landam commented 5 years ago

Comment by hellik on 2 Jan 2019 08:38 UTC Replying to [comment:7 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.

landam commented 5 years ago

Comment by @landam on 3 Jan 2019 21:54 UTC Replying to [comment:9 hellik]:

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

you are right, changing milestone

landam commented 5 years ago

Comment by @landam on 3 Jan 2019 22:03 UTC In [changeset:"73905\"] https://trac.osgeo.org/grass/changeset/73905:

Shlib.make: MinGW's 'ln' just copies the file, see #1
landam commented 5 years ago

Comment by @landam on 3 Jan 2019 22:06 UTC Replying to [comment:8 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 ;-)

landam commented 5 years ago

Comment by hellik on 4 Jan 2019 07:43 UTC Replying to [comment:12 martinl]:

Replying to [comment:8 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.
landam commented 5 years ago

Comment by @landam on 7 Jan 2019 20:58 UTC ah, I see, reverted in https://trac.osgeo.org/grass/changeset/73921

landam commented 5 years ago

Comment by @landam on 7 Jan 2019 21:13 UTC 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