[GRASS5] Strange NVIZ behavior by displaying 3D-Polygons (GRASS 5.7)

lesejk · March 30, 2004, 5:29pm

Hallo,
I'm using GRASS 5.7, snapshot from 2004_03_27, own compilation on
Slackware.

When I run NVIZ with some 3D polygons (NOT lines), by changing the point
of view, the color of the raster surface becomes black.

You can't do anything with it, only to restart NVIZ.
The underside of the raster has the "normal" color palette.

When you are running NVIZ with vector lines or without any vector data,
everything works fine.

Radim's sample dataset does it too (with house_roof,house_wall),
so I suppose, there is no bug in my data.

The snapshot from 2003_10_04 (with some older NVIZ version) does not
have these problem. So I suppose, there is some little bug in the new
version of NVIZ.

Thank you

Jáchym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz

Helena_Mitasova · May 6, 2004, 5:17am

I have discussed with Paul the possibility to release GRASS5.3
this month (as the effort to release it somehow keeps dying).
To do that nothing new should be contributed to 5.3 by now,
except for bug fixes. All new development should go into 5.7.
To make this clear I would like to modify the web site as follows:

5.0.x: Current Stable: 5.0.3 [info]
5.3.x: Closed for development, getting ready for release: 5.3-cvs [info]
5.7.x: Current development: 5.7-cvs [info]

Once the release is successful it should be changed to :
5.4.x: Current Stable: 5.4.0 [info] (is this right???)
5.7.x: Current development: 5.7-cvs [info]

Please let me know if this is correct or
if you have a better suggestion, I will be happy to follow any advice
that can make the release happen in May smoothly.
Then all of us can focus on 5.7 following the suggestions
in the roadmap http://grass.itc.it/roadmap.html

thank you,

Helena

H_B · May 6, 2004, 5:12am

I have discussed with Paul the possibility to release GRASS5.3
this month (as the effort to release it somehow keeps dying).

Any reason not to tag a 5.7.0 at the same time? (or waiting until Radim
has finalized the vector format changes if that's not far off)

Benchmark versions are good to look back on sometimes.

??

Hamish

H_B · May 6, 2004, 6:55am

I have discussed with Paul the possibility to release GRASS5.3
this month (as the effort to release it somehow keeps dying).
To do that nothing new should be contributed to 5.3 by now,
except for bug fixes. All new development should go into 5.7.

my suggested list of things to do for 5.4.0:

target features status
------------------------------------ --------
Datum Support done
g.setproj & m.proj2 solid pretty good?
gdal req'd, get rid of gdal bridge? ?
all scripts -> g.parser ?
missing man pages (Debian bug #229086, 242436) no
Remove any remaining GD,GDBM mentions ?
init.sh/set_data race ??? not sure what this was about
NVIZ updates done
add r.series, r.grow2, d.info **TODO**
add r.[in|out].mat, r.univar(2) **TODO**
OSX TclTk -> Aqua so close
TrueColor for core display modules C done; man pages?
shared libs working on all but Cygwin ?
merge updated Tcl Menus Scott
finish v.in.garmin auto-projection for WGS84 Hamish

Release Critical Bugs status
------------------------------------ --------
r.in.gdal bug free done (I think)
OSX won't start [rm .grassrc5] ?
r.series to sample variance (n-1) + document ? ok to do?
NVIZ on Debian with TclTk 8.4 no
NVIZ with generic TclTk 8.5 ?
r.terraflow #if GCC>3.0 include rules no, but works
others?

---

New feature freeze for anything else after 5.3.0.
"Bug fix only" freeze for anything else after 5.3.1. (1 month?)
[difference is module behaviour changes, etc ?]

---

my suggested list of things to do for 5.7.x:

target features status
------------------------------------ --------
finalize vector format + solid pending
solid DB integation
move -> OGR storage no
merge r.average et al. no
merge 5.3 code after 5.3.1 is tagged ? not yet
new build system done
s.convert 5.0->5.7 sites full cat/att support no?
Add /* $Id$ */ to all C files in progress
Add # $Id$ to all scripts in progress
Add  to all html ?
Add Last changed $Date$ to all description.html parser?
Add consistent license comments to those without or not?

just some ideas,
Hamish

Radim_Blazek · May 6, 2004, 9:05am

On Thursday 06 May 2004 07:12, Hamish wrote:

> I have discussed with Paul the possibility to release GRASS5.3
> this month (as the effort to release it somehow keeps dying).

Any reason not to tag a 5.7.0 at the same time?

Any reason to do that? If this:

On Thursday 06 May 2004 07:17, Helena wrote:

To do that nothing new should be contributed to 5.3 by now,
except for bug fixes. All new development should go into 5.7.

Once the release is successful it should be changed to :
5.4.x: Current Stable: 5.4.0 [info] (is this right???)

becomes true before 5.7.0, no need to tag 'grass' module with 5.7.0 tag I think.
But I don't believe it happens.

(or waiting until Radim has finalized the vector format changes if that's not far off)

I want to release 5.7.0 before this summer. My plan is

< 14.5. - add OGR to vector library
         - add ogr DB driver
         - enable writing of new 'coor' format
< 21.5. - remove Shapefile and PostGIS from vector library (substituted by OGR)
         - remove shp DB driver
         - add support for 'NULL' in dbf DB driver
         - new feature freez, bugfixing only (targeted on smooth compilation
           on major platforms)
7.6.(-11.6.) - release 5.7.0 (tag grass51 and grass modules)
             - thaw 5.7 for new features

On Thursday 06 May 2004 08:55, Hamish wrote:

my suggested list of things to do for 5.7.x:
target features status
------------------------------------ --------
finalize vector format + solid pending

What is 'solid'? 3D or quality code?
But it does not matter as non of them can be in 5.7.0

solid DB integation

Whats this? Who is going to do that?

move -> OGR storage no

Whats this? Direct OGR support (see above) or something else.

merge r.average et al. no

OK, if somebody does that, but I'll not wait for it.

merge 5.3 code after 5.3.1 is tagged ? not yet

Copy files from grass to grass51? We should seriously consider again
to merge grass51 back to grass, but I think that it is more painful
than vice versa. 'New' history is more important than 'old' history.
If copy from grass to grass51, each file should have
source path in the first log in identical format.

new build system done
s.convert 5.0->5.7 sites full cat/att support no?

??? v.in.sites

Add /* $Id$ */ to all C files in progress
Add # $Id$ to all scripts in progress
Add  to all html ?
Add Last changed $Date$ to all description.html parser?

$Id$ was recommended first in grass/SUBMITTING and removed later (2002/03/06):
http://freegis.org/cgi-bin/viewcvs.cgi/grass/SUBMITTING.diff?r1=1.20&r2=1.21

It is not something which should block 5.7.0 anyway.

Add consistent license comments to those without or not?

Where, in external libraries using non GPL?

Radim

Paul_Kelly · May 6, 2004, 11:15pm

Hamish wrote:

> I have discussed with Paul the possibility to release GRASS5.3
> this month (as the effort to release it somehow keeps dying).
> To do that nothing new should be contributed to 5.3 by now,
> except for bug fixes. All new development should go into 5.7.

my suggested list of things to do for 5.4.0:

target features status
------------------------------------ --------
Datum Support done
g.setproj & m.proj2 solid pretty good?
gdal req'd, get rid of gdal bridge? ?

GDAL should be optional---it is only actually used for r.in.gdal and
there are alternatives like r.in.tiff

all scripts -> g.parser ?
missing man pages (Debian bug #229086, 242436) no
Remove any remaining GD,GDBM mentions ?
init.sh/set_data race ??? not sure what this was about
NVIZ updates done
add r.series, r.grow2, d.info **TODO**
add r.[in|out].mat, r.univar(2) **TODO**
OSX TclTk -> Aqua so close
TrueColor for core display modules C done; man pages?
shared libs working on all but Cygwin ?

Not a big job to get them working on Cygwin:
1) make driverlib static on all platforms (I remember Glynn saying this
was generally a good idea as the way it is written it will always
reference functions in other libraries that might not have been compiled
yet)
2) merge dig2lib and vectlib into 1 big library (any module that links
to them always links to both)
After that I think it will work fine on Cygwin.
Getting it working on OSX is a bigger problem and requires lots of
tedious work removing multiply defined symbols, but will be done for 5.4

merge updated Tcl Menus Scott
finish v.in.garmin auto-projection for WGS84 Hamish

Release Critical Bugs status
------------------------------------ --------
r.in.gdal bug free done (I think)
OSX won't start [rm .grassrc5] ?
r.series to sample variance (n-1) + document ? ok to do?
NVIZ on Debian with TclTk 8.4 no
NVIZ with generic TclTk 8.5 ?
r.terraflow #if GCC>3.0 include rules no, but works

Only compile r.terraflow if g++ is the compiler
Fix r.terraflow makefiles so they work with alternate build mechanism

others?

---

New feature freeze for anything else after 5.3.0.
"Bug fix only" freeze for anything else after 5.3.1. (1 month?)

Bug fix only is after 5.4.0. Technically all 5.3.x releases can add new
features as 3 is an odd number, as I understand it.

[difference is module behaviour changes, etc ?]

---

my suggested list of things to do for 5.7.x:

And after 5.4.0 there will be no-one working on the 'grass' CVS module
so everybody can help with this stuff in 'grass51'

target features status
------------------------------------ --------
finalize vector format + solid pending
solid DB integation
move -> OGR storage no
merge r.average et al. no
merge 5.3 code after 5.3.1 is tagged ? not yet

Not until this isn't going to change any more, i.e. after 5.4.0. After
that bugfixes will have to be done to files both in 5.7 and in the 5.4
release branch, but this should be not a lot more tedious than having to
do them in the 5.0 releasebranch and HEAD at the minute

new build system done

I think the shared library support could be re-done again using the
aclocal.m4 from 5.3 but we are better waiting for further testing of it
there (which won't happen until --enable-gmake=no is the default but
must get it working on Cygwin and OSX first)

s.convert 5.0->5.7 sites full cat/att support no?
Add /* $Id$ */ to all C files in progress
Add # $Id$ to all scripts in progress
Add  to all html ?
Add Last changed $Date$ to all description.html parser?
Add consistent license comments to those without or not?

just some ideas,
Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

Glynn_Clements · May 7, 2004, 12:35am

Paul Kelly wrote:

> shared libs working on all but Cygwin ?

Not a big job to get them working on Cygwin:

No? Is it no longer necessary to create a .def file for DLLs?

1) make driverlib static on all platforms (I remember Glynn saying this
was generally a good idea as the way it is written it will always
reference functions in other libraries that might not have been compiled
yet)

Actually, the issues are:

a) that driverlib references functions which are defined in the
executable, and

b) main() is defined in the library.

Getting it working on OSX is a bigger problem and requires lots of
tedious work removing multiply defined symbols, but will be done for 5.4

Can you provide more details? Maybe I'm missing something, but I can
only find around 20 symbols which appear to be problematic.

--
Glynn Clements <glynn.clements@virgin.net>

H_B · May 7, 2004, 2:22am

> r.terraflow #if GCC>3.0 include rules no, but works

Only compile r.terraflow if g++ is the compiler

That is what the GCC version check is for. I'm pretty sure if we (I)
conditionalize all the GCC 3+ includes, it will compile with cc. ?

http://article.gmane.org/gmane.comp.gis.grass.devel/2923
http://article.gmane.org/gmane.comp.gis.grass.devel/2932

Fix r.terraflow makefiles so they work with alternate build mechanism

Beyond applying these changes to 5.3, what else needs to be done?

http://article.gmane.org/gmane.comp.gis.grass.devel/3662
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/raster/r.terraflow/Makefile
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/raster/r.terraflow/IOStream/lib/Makefile

Hamish

Paul_Kelly · May 7, 2004, 9:19am

On Fri, 7 May 2004, Glynn Clements wrote:

Paul Kelly wrote:

> > shared libs working on all but Cygwin ?
>
> Not a big job to get them working on Cygwin:

No? Is it no longer necessary to create a .def file for DLLs?

Mmm well I'm just saying it seems to work for me with driverlib, dig2lib
and vect2lib all compiled statically and everything else as DLLs. GRASS
starts, seems to run, displaying and querying maps works etc.
What should I be looking for to go wrong if there is no .def file? This is
running on Windows 2000. I am setting up the Windows machine for a final
year project student to use so maybe I will get more feedback on it next
week.

> 1) make driverlib static on all platforms (I remember Glynn saying this
> was generally a good idea as the way it is written it will always
> reference functions in other libraries that might not have been compiled
> yet)

Actually, the issues are:

a) that driverlib references functions which are defined in the
executable, and

b) main() is defined in the library.

> Getting it working on OSX is a bigger problem and requires lots of
> tedious work removing multiply defined symbols, but will be done for 5.4

Can you provide more details? Maybe I'm missing something, but I can
only find around 20 symbols which appear to be problematic.

Not just for driverlib; Lorenzo Moretti has done useful work compiling and
reporting the errors:

http://wwwamb.bologna.enea.it/forgrass/Errors_Grass53_2004_04_24_shared_lib.txt

Paul

Paul_Kelly · May 7, 2004, 9:25am

On Fri, 7 May 2004, Hamish wrote:

> > r.terraflow #if GCC>3.0 include rules no, but works
>
> Only compile r.terraflow if g++ is the compiler

That is what the GCC version check is for. I'm pretty sure if we (I)
conditionalize all the GCC 3+ includes, it will compile with cc. ?

http://article.gmane.org/gmane.comp.gis.grass.devel/2923
http://article.gmane.org/gmane.comp.gis.grass.devel/2932

Well I'm pretty sure it won't compile with the IRIX CC but I don't
mind. The original version of r.terraflow in GRASS didn't have the GCC
3-style includes and there were a lot more errors then:
http://grass.itc.it/pipermail/grass5/2003-February/007312.html
but I'm willing to try compiling again. Laura said she didn't expect it to
work with anything but g++ so I'm also going by that.

> Fix r.terraflow makefiles so they work with alternate build mechanism

Beyond applying these changes to 5.3, what else needs to be done?

The way it makes two sub-directories to compile different versions of the
program trips up the sed script that converts the Gmakefiles into
makefiles for the alternate build mechanism, Haven't looked into it more
than that.

Paul

neteler · May 7, 2004, 12:25pm

On Fri, May 07, 2004 at 01:35:16AM +0100, Glynn Clements wrote:

Paul Kelly wrote:

[...]

> Getting it working on OSX is a bigger problem and requires lots of
> tedious work removing multiply defined symbols, but will be done for 5.4

Can you provide more details? Maybe I'm missing something, but I can
only find around 20 symbols which appear to be problematic.

Weeks ago I have resolved quite a few symbols for OSX,
so I don't think that this is much work (1 hour?).

But I have no OSX access, so I cannot continue and also lack
some time. Locally I am using
CFLAGS='-g -Wall -Werror-implicit-function-declaration -fno-common'
to simulate the behaviour of the OSX compiler on Linux, but
it doesn't seem to catch all problems.

Markus

Glynn_Clements · May 8, 2004, 1:56am

Paul Kelly wrote:

> > > shared libs working on all but Cygwin ?
> >
> > Not a big job to get them working on Cygwin:
>
> No? Is it no longer necessary to create a .def file for DLLs?

Mmm well I'm just saying it seems to work for me with driverlib, dig2lib
and vect2lib all compiled statically and everything else as DLLs. GRASS
starts, seems to run, displaying and querying maps works etc.
What should I be looking for to go wrong if there is no .def file?

You should be looking for the attempt to build the DLL failing
completely and obviously. If you are ending up with actual DLLs then
it appears that you don't need a .def file.

So, it appears that "gcc -shared" now works on Cygwin; you used to
have to create a .def file then use "dlltool" to actually build a DLL
from a bunch of .o files.

> > Getting it working on OSX is a bigger problem and requires lots of
> > tedious work removing multiply defined symbols, but will be done for 5.4
>
> Can you provide more details? Maybe I'm missing something, but I can
> only find around 20 symbols which appear to be problematic.

Not just for driverlib; Lorenzo Moretti has done useful work compiling and
reporting the errors:

http://wwwamb.bologna.enea.it/forgrass/Errors_Grass53_2004_04_24_shared_lib.txt

Right. The -fno-common switch (as suggested by Markus) should catch
most of those.

--
Glynn Clements <glynn.clements@virgin.net>

Glynn_Clements · May 8, 2004, 2:08am

Paul Kelly wrote:

> > > r.terraflow #if GCC>3.0 include rules no, but works
> >
> > Only compile r.terraflow if g++ is the compiler
>
> That is what the GCC version check is for. I'm pretty sure if we (I)
> conditionalize all the GCC 3+ includes, it will compile with cc. ?
>
> http://article.gmane.org/gmane.comp.gis.grass.devel/2923
> http://article.gmane.org/gmane.comp.gis.grass.devel/2932

Well I'm pretty sure it won't compile with the IRIX CC but I don't
mind. The original version of r.terraflow in GRASS didn't have the GCC
3-style includes and there were a lot more errors then:
http://grass.itc.it/pipermail/grass5/2003-February/007312.html
but I'm willing to try compiling again. Laura said she didn't expect it to
work with anything but g++ so I'm also going by that.

FWIW, I don't think that we should attempt to work around actual
deficiencies in C++ compilers, but nor I do think that we should
accept code which is gratuitously non-portable. IOW, "requires an
ANSI-compliant C++ compiler" is OK; "requires g++" isn't.

Those gcc-specific switches should be removed from the Gmakefile; the
user can set CXXFLAGS when running configure if they want to add them.

--
Glynn Clements <glynn.clements@virgin.net>

Radim_Blazek · May 14, 2004, 9:20am

On Thursday 06 May 2004 11:05, Radim Blazek wrote:

I want to release 5.7.0 before this summer. My plan is

< 14.5. - add OGR to vector library
- add ogr DB driver
- enable writing of new 'coor' format

Done

< 21.5. - remove Shapefile and PostGIS from vector library
(substituted by OGR) - remove shp DB driver
- add support for 'NULL' in dbf DB driver

- use DBMI instead of Postgres in NVIZ

- new feature freez, bugfixing only (targeted
on smooth compilation on major platforms)

7.6.(-11.6.) - release 5.7.0 (tag grass51 and grass modules)
- thaw 5.7 for new features

Radim

Radim_Blazek · May 21, 2004, 2:46pm

I have removed Shapefile/PostGIS support from vector library
and enabled multi sessions. Please test!
I want to release 5.7.0 7.-11. June.

Radim

Craig_Funk · May 21, 2004, 3:18pm

Hi Radim, Could this be possibly causing some compile problems. I have fresh source and I am getting compile errors in Vlib like:

close_post.c: In function `V1_close_post':
close_post.c:51: warning: implicit declaration of function `PQfinish'
close_post.c:51: error: structure has no member named `post'

and

build_shp.c: In function `Vect_build_shp':
build_shp.c:57: error: structure has no member named `shp'
build_shp.c:64: error: structure has no member named `shp'
build_shp.c:65: error: structure has no member named `shp'
build_shp.c:66: error: structure has no member named `shp'
build_shp.c:74: warning: implicit declaration of function `V1_read_next_line_shp'
build_shp.c:80: warning: implicit declaration of function `Vect_last_line_offset_shp'
build_shp.c:97: warning: passing arg 1 of `G_malloc' as signed due to prototype
build_shp.c:98: warning: passing arg 1 of `G_malloc' as signed due to prototype
build_shp.c:99: warning: passing arg 1 of `G_malloc' as signed due to prototype
build_shp.c:107: error: structure has no member named `shp'
build_shp.c:111: warning: passing arg 2 of `G_realloc' as signed due to prototype
build_shp.c:112: warning: passing arg 2 of `G_realloc' as signed due to prototype
build_shp.c:113: warning: passing arg 2 of `G_realloc' as signed due to prototype
build_shp.c:132: warning: passing arg 4 of `Vect_append_point' as floating rather than integer due to prototype
build_shp.c:232: warning: passing arg 4 of `Vect_append_point' as floating rather than integer due to prototype

It seems to be related to:
struct Format_info {
int i;
#ifdef HAVE_OGR
struct Format_info_ogr ogr;
#endif
} ;

which has no members shp or post, etc.

How do I fix this?

Thanx
Craig

On 21-May-04, at 8:46 AM, Radim Blazek wrote:

I have removed Shapefile/PostGIS support from vector library
and enabled multi sessions. Please test!
I want to release 5.7.0 7.-11. June.

Radim

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

mlennert · May 21, 2004, 3:30pm

Funkmeister said:

Hi Radim, Could this be possibly causing some compile problems. I have
fresh source and I am getting compile errors in Vlib like:

close_post.c: In function `V1_close_post':
close_post.c:51: warning: implicit declaration of function `PQfinish'
close_post.c:51: error: structure has no member named `post'

and

build_shp.c: In function `Vect_build_shp':
build_shp.c:57: error: structure has no member named `shp'
build_shp.c:64: error: structure has no member named `shp'
build_shp.c:65: error: structure has no member named `shp'
build_shp.c:66: error: structure has no member named `shp'
build_shp.c:74: warning: implicit declaration of function
`V1_read_next_line_shp'
build_shp.c:80: warning: implicit declaration of function
`Vect_last_line_offset_shp'
build_shp.c:97: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:98: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:99: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:107: error: structure has no member named `shp'
build_shp.c:111: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:112: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:113: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:132: warning: passing arg 4 of `Vect_append_point' as
floating rather than integer due to prototype
build_shp.c:232: warning: passing arg 4 of `Vect_append_point' as
floating rather than integer due to prototype

Just to confirm/amend: I have the same problem with build_shp.c, but
nothing concerning close_post.c. My configure statement is as follows:

CFLAGS="-g -Wall" ./configure
--with-grass50=/data/CVS/GRASSCVS/grass-5.3.0
--with-tcltk-includes=/usr/include/tcl8.3/
--with-postgres-includes="/usr/include/postgresql/
/usr/include/postgresql/internal/" --with-readline --with-dbm
--with-includes="/usr/include/ /usr/local/include/" --with-libs="/usr/lib/
/usr/local/lib" --with-gdal=/usr/bin/gdal-config

Moritz

Radim_Blazek · May 21, 2004, 4:02pm

Sorry, I forgot to commit deleted files, fixed now, update
lib/vector/Vlib or simply delete lib/vector/Vlib/*_shp.c
lib/vector/Vlib/*_post.c

Radim

On Friday 21 May 2004 17:18, Funkmeister wrote:

Hi Radim, Could this be possibly causing some compile problems. I have
fresh source and I am getting compile errors in Vlib like:

close_post.c: In function `V1_close_post':
close_post.c:51: warning: implicit declaration of function `PQfinish'
close_post.c:51: error: structure has no member named `post'

and

build_shp.c: In function `Vect_build_shp':
build_shp.c:57: error: structure has no member named `shp'
build_shp.c:64: error: structure has no member named `shp'
build_shp.c:65: error: structure has no member named `shp'
build_shp.c:66: error: structure has no member named `shp'
build_shp.c:74: warning: implicit declaration of function
`V1_read_next_line_shp'
build_shp.c:80: warning: implicit declaration of function
`Vect_last_line_offset_shp'
build_shp.c:97: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:98: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:99: warning: passing arg 1 of `G_malloc' as signed due to
prototype
build_shp.c:107: error: structure has no member named `shp'
build_shp.c:111: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:112: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:113: warning: passing arg 2 of `G_realloc' as signed due to
prototype
build_shp.c:132: warning: passing arg 4 of `Vect_append_point' as
floating rather than integer due to prototype
build_shp.c:232: warning: passing arg 4 of `Vect_append_point' as
floating rather than integer due to prototype

It seems to be related to:
struct Format_info {
int i;
#ifdef HAVE_OGR
struct Format_info_ogr ogr;
#endif
} ;

which has no members shp or post, etc.

How do I fix this?

Thanx
Craig

On 21-May-04, at 8:46 AM, Radim Blazek wrote:
> I have removed Shapefile/PostGIS support from vector library
> and enabled multi sessions. Please test!
> I want to release 5.7.0 7.-11. June.
>
> Radim
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

mlennert · May 21, 2004, 5:04pm

Radim Blazek said:

I have removed Shapefile/PostGIS support from vector library
and enabled multi sessions. Please test!

If multi-sessions mean that you can open multiple GRASS sessions, but not
on the same mapset, than it seems to work (only superficial testing).

Moritz

Gino_Pirelli · May 26, 2004, 10:55am

Hi at all,

expecially to Radim that developped this plugin.

I've this compilation problem after introducing gdal patchs:

g++ ogrinfo.o -o .libs/ogrinfo ../.libs/libgdal.so -lodbc -lpng -L/home/riade/src/grass/grass-5.7_exp_26052004/dist.i686-pc-linux-gnu/ -L/home/riade/src/grass/grass-5.7_exp_26052004/dist.i686-pc-linux-gnu//lib /usr/local/lib/libgrass5.so -lnsl -lz -ldl -L/usr/local/pgsql/lib -lpq -Wl,--rpath -Wl,/usr/local/lib
../.libs/libgdal.so: undefined reference to `G_add_mapset_to_search_path'
../.libs/libgdal.so: undefined reference to `GPJ_grass_to_wkt'
../.libs/libgdal.so: undefined reference to `G_set_gisrc_mode'

`G_add_mapset_to_search_path', `GPJ_grass_to_wkt' and `G_set_gisrc_mode' are not presente in lates libgrass (today cvs version), but are present in:

libgrass_gis.so libgrass_gproj.so of the latest cvs release of 5.7.

How resolve?

thanks,

BeSoS Luis