Glynn Clements wrote:
I've just committed a substantial restructuring of the display
drivers. The actual code hasn't changed much, but there has been quite
a lot of re-organisation. Please test any d.* modules which you are
familiar with.
The most significant code change is that the driver library no longer
provides a main() function, and doesn't expect the driver to export
specific symbols. Instead, each driver has its own "stub" main
function which calls LIB_main(), passing a table of pointers to the
actual driver functions.
This eliminates the assumptions regarding the behaviour of the linker.
It should be possible to build the driver library as a dynamic library
on all platforms which support dynamic libraries.
I haven't updated the HTMLMAP driver, so it won't build any more.
AFAIK, it wasn't being used due to the fact that d.vect uses
G_plot_area rather than R_polygon_abs, which doesn't work with the
HTMLMAP driver.
I just updated my cvs tree and recompiled, and now I cannot start a monitor anymore:
d.mon start=x0
Could not execute monitor: No such file or directory
No socket to connect to for monitor <x0>.
Problem selecting x0. Will try once more
No socket to connect to for monitor <x0>.
Is this related ?
Moritz
Moritz Lennert wrote:
Glynn Clements wrote:
I've just committed a substantial restructuring of the display
drivers. The actual code hasn't changed much, but there has been quite
a lot of re-organisation. Please test any d.* modules which you are
familiar with.
The most significant code change is that the driver library no longer
provides a main() function, and doesn't expect the driver to export
specific symbols. Instead, each driver has its own "stub" main
function which calls LIB_main(), passing a table of pointers to the
actual driver functions.
This eliminates the assumptions regarding the behaviour of the linker.
It should be possible to build the driver library as a dynamic library
on all platforms which support dynamic libraries.
I haven't updated the HTMLMAP driver, so it won't build any more.
AFAIK, it wasn't being used due to the fact that d.vect uses
G_plot_area rather than R_polygon_abs, which doesn't work with the
HTMLMAP driver.
I just updated my cvs tree and recompiled, and now I cannot start a monitor anymore:
d.mon start=x0
Could not execute monitor: No such file or directory
No socket to connect to for monitor <x0>.
Problem selecting x0. Will try once more
No socket to connect to for monitor <x0>.
I also cannot launch gis.m anymore:
gis.m
Could not execute monitor: No such file or directory
Moritz
Moritz Lennert wrote:
Moritz Lennert wrote:
Glynn Clements wrote:
I've just committed a substantial restructuring of the display
drivers. The actual code hasn't changed much, but there has been quite
a lot of re-organisation. Please test any d.* modules which you are
familiar with.
The most significant code change is that the driver library no longer
provides a main() function, and doesn't expect the driver to export
specific symbols. Instead, each driver has its own "stub" main
function which calls LIB_main(), passing a table of pointers to the
actual driver functions.
This eliminates the assumptions regarding the behaviour of the linker.
It should be possible to build the driver library as a dynamic library
on all platforms which support dynamic libraries.
I haven't updated the HTMLMAP driver, so it won't build any more.
AFAIK, it wasn't being used due to the fact that d.vect uses
G_plot_area rather than R_polygon_abs, which doesn't work with the
HTMLMAP driver.
I just updated my cvs tree and recompiled, and now I cannot start a monitor anymore:
d.mon start=x0
Could not execute monitor: No such file or directory
No socket to connect to for monitor <x0>.
Problem selecting x0. Will try once more
No socket to connect to for monitor <x0>.
I also cannot launch gis.m anymore:
gis.m
Could not execute monitor: No such file or directory
Here are the compilation error messages:
grass6/display/drivers/lib$ make
gcc -I/home/mlennert/SRC/GRASS/grass6/include -I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass -Wall -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -I/usr/include/freetype2 -DPACKAGE=\""grasslibs"\" -I/home/mlennert/SRC/GRASS/grass6/include -I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass \
-o OBJ.i486-pc-linux-gnu/font.o -c font.c
font.c:10: error: 'index' redeclared as different kind of symbol
font.c: In function 'font_init':
font.c:49: warning: passing argument 3 of 'read' as unsigned due to prototype
make: *** [OBJ.i486-pc-linux-gnu/font.o] Erreur 1
and the follow-up of this:
grass6/display/drivers/XDRIVER$ make
make: *** No rule to make target `/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/lib/libgrass_driver.so', needed by `/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/driver/XDRIVER'. Stop.
grass6/display/drivers/PNG$ make
make: *** No rule to make target `/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/lib/libgrass_driver.so', needed by `/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/driver/PNG'. Stop.
Moritz
Moritz Lennert wrote:
Here are the compilation error messages:
grass6/display/drivers/lib$ make
gcc -I/home/mlennert/SRC/GRASS/grass6/include
-I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass
-Wall -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC
-DPACKAGE=\""grasslibs"\" -I/usr/include/freetype2
-DPACKAGE=\""grasslibs"\" -I/home/mlennert/SRC/GRASS/grass6/include
-I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass \
-o OBJ.i486-pc-linux-gnu/font.o -c font.c
font.c:10: error: 'index' redeclared as different kind of symbol
This should be fixed now.
AFAICT, all of the other issues stem from this error.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Moritz Lennert wrote:
Here are the compilation error messages:
grass6/display/drivers/lib$ make
gcc -I/home/mlennert/SRC/GRASS/grass6/include -I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass -Wall -g -O2 -Wall -Wconversion -Wno-implicit-int -fPIC -DPACKAGE=\""grasslibs"\" -I/usr/include/freetype2 -DPACKAGE=\""grasslibs"\" -I/home/mlennert/SRC/GRASS/grass6/include -I/home/mlennert/SRC/GRASS/grass6/dist.i486-pc-linux-gnu/include/grass \
-o OBJ.i486-pc-linux-gnu/font.o -c font.c
font.c:10: error: 'index' redeclared as different kind of symbol
This should be fixed now.
AFAICT, all of the other issues stem from this error.
Yes, everything works again.
Thanks Glynn !
Moritz