Hi,
I don't know what changed but I don't manage any more to compile the
GDAL-GRASS-plugin without tricks:
config.log of GDAL-GRASS-plugin:
...
configure:3017: checking for G_putenv in -lgrass_gis
configure:3047: gcc -o conftest -O2 conftest.c -lgrass_gis
-L/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib
-lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect
-lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2
-lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_gmath
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_datetime
/usr/bin/ld: cannot find -lgrass_gproj
/usr/bin/ld: cannot find -lgrass_vect
/usr/bin/ld: cannot find -lgrass_dbmibase
/usr/bin/ld: cannot find -lgrass_dbmiclient
/usr/bin/ld: cannot find -lgrass_dgl
/usr/bin/ld: cannot find -lgrass_dig2
/usr/bin/ld: cannot find -lgrass_rtree
/usr/bin/ld: cannot find -lgrass_linkm
...
All names are currently libgrass_raster.6.4.2svn.so and likewise.
Starting gdalinfo etc, tells me
libgrass_I.so not found
I can solve the problem like this:
cd /where/grass64/is/lib/
for i in `ls libgrass_*.6.4.*` ; do ln -s $i `basename $i 6.4.2svn.so`so ; done
Any ideas?
Markus
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
I don't know what changed but I don't manage any more to compile the
GDAL-GRASS-plugin without tricks:
config.log of GDAL-GRASS-plugin:
...
configure:3017: checking for G_putenv in -lgrass_gis
configure:3047: gcc -o conftest -O2 conftest.c -lgrass_gis
-L/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib
-lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect
-lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2
-lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_gmath
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_datetime
/usr/bin/ld: cannot find -lgrass_gproj
/usr/bin/ld: cannot find -lgrass_vect
/usr/bin/ld: cannot find -lgrass_dbmibase
/usr/bin/ld: cannot find -lgrass_dbmiclient
/usr/bin/ld: cannot find -lgrass_dgl
/usr/bin/ld: cannot find -lgrass_dig2
/usr/bin/ld: cannot find -lgrass_rtree
/usr/bin/ld: cannot find -lgrass_linkm
...
All names are currently libgrass_raster.6.4.2svn.so and likewise.
Starting gdalinfo etc, tells me
libgrass_I.so not found
I can solve the problem like this:
cd /where/grass64/is/lib/
for i in `ls libgrass_*.6.4.*` ; do ln -s $i `basename $i 6.4.2svn.so`so ; done
building system in GRASS 7 doesn't produce unversioned library names.
Symlinks don't work on Windows, this change has been backported some
months ago to devbr6 and recently also to relbr64 (for 6.4.2).
GDAL-GRASS-plugin needs to updated (to use only versioned library
names).
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Apr 18, 2011 at 9:41 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
I don't know what changed but I don't manage any more to compile the
GDAL-GRASS-plugin without tricks:
config.log of GDAL-GRASS-plugin:
...
configure:3017: checking for G_putenv in -lgrass_gis
configure:3047: gcc -o conftest -O2 conftest.c -lgrass_gis
-L/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib
-lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect
-lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2
-lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_gmath
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_datetime
/usr/bin/ld: cannot find -lgrass_gproj
/usr/bin/ld: cannot find -lgrass_vect
/usr/bin/ld: cannot find -lgrass_dbmibase
/usr/bin/ld: cannot find -lgrass_dbmiclient
/usr/bin/ld: cannot find -lgrass_dgl
/usr/bin/ld: cannot find -lgrass_dig2
/usr/bin/ld: cannot find -lgrass_rtree
/usr/bin/ld: cannot find -lgrass_linkm
...
All names are currently libgrass_raster.6.4.2svn.so and likewise.
Starting gdalinfo etc, tells me
libgrass_I.so not found
I can solve the problem like this:
cd /where/grass64/is/lib/
for i in `ls libgrass_*.6.4.*` ; do ln -s $i `basename $i 6.4.2svn.so`so ; done
building system in GRASS 7 doesn't produce unversioned library names.
Symlinks don't work on Windows, this change has been backported some
months ago to devbr6 and recently also to relbr64 (for 6.4.2).
OK.
GDAL-GRASS-plugin needs to updated (to use only versioned library
names).
This is fairly unlikely to happen (in GDAL) so many packagers may start
to drop this important plugin.
Suggestion: Create the symlinks on Linux and MacOSX only with a
condition.
?
Markus
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
GDAL-GRASS-plugin needs to updated (to use only versioned library
names).
This is fairly unlikely to happen (in GDAL) so many packagers may start
to drop this important plugin.
why do you think so.
Suggestion: Create the symlinks on Linux and MacOSX only with a
condition.
?
Probably yes.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Apr 18, 2011 at 9:50 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
GDAL-GRASS-plugin needs to updated (to use only versioned library
names).
This is fairly unlikely to happen (in GDAL) so many packagers may start
to drop this important plugin.
why do you think so.
Because in the past it was not so easy to get changes to the plugin through
and my patches for GRASS 7 are sleeping in the GDAL trac for already
2 years..:
http://trac.osgeo.org/gdal/ticket/2953
Suggestion: Create the symlinks on Linux and MacOSX only with a
condition.
?
Probably yes.
Then that would be the "least cost" path IMHO rather than bothering elsewhere.
Markus
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
This is fairly unlikely to happen (in GDAL) so many packagers may start
to drop this important plugin.
why do you think so.
Because in the past it was not so easy to get changes to the plugin through
and my patches for GRASS 7 are sleeping in the GDAL trac for already
2 years..:
http://trac.osgeo.org/gdal/ticket/2953
I have write access to GDAL, so probably I could help with that.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Apr 18, 2011 at 10:09 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
This is fairly unlikely to happen (in GDAL) so many packagers may start
to drop this important plugin.
why do you think so.
Because in the past it was not so easy to get changes to the plugin through
and my patches for GRASS 7 are sleeping in the GDAL trac for already
2 years..:
http://trac.osgeo.org/gdal/ticket/2953
I have write access to GDAL, so probably I could help with that.
That's nice, I forgot. However, eventually a new GDAL-GRASS plugin would
be needed and all packagers be informed.
Markus
Hi,
2011/4/18 Markus Neteler <neteler@osgeo.org>:
That's nice, I forgot. However, eventually a new GDAL-GRASS plugin would
be needed and all packagers be informed.
right, GRASS 6 building system should probably produced also
unversioned library names. Anyway GDAL-GRASS plugin should be fixed in
any case.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin Landa wrote:
> That's nice, I forgot. However, eventually a new GDAL-GRASS plugin would
> be needed and all packagers be informed.
right, GRASS 6 building system should probably produced also
unversioned library names.
I'd suggest installing a script which generates the unversioned names.
If we generate the symlinks autmatically:
1. If something uses the unversioned name by mistake, we don't get an
error.
2. Windows builds will end up with two copies of each library (the
MSys version of "ln" simply copies the file).
For GRASS itself, #2 is mostly harmless; the unversioned copies will
be unused (they should be omitted from binary packages).
But the GDAL-GRASS plugin probably won't work, as the plugin will be
linked against the unversioned libraries while the unversioned
libraries will be linked against the versioned libraries. So any
process using the plugin will end up pulling in both copies, and each
copy will have its own distinct set of global variables.
--
Glynn Clements <glynn@gclements.plus.com>