Hi all,
a somewhat strange thing I found in r.in.shape Gmakefile:
Using the LIBES line like that:
LIBES=$(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
I get this compilation error:
gcc -s -o
/home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape
OBJ.i686-pc-linux-gnu/main.o
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvect.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libgis.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvask.a -lncurses
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdatetime.a
/home/neteler/ggg/src/libes/vect32_64/shapelib-1.2.8/LIB.i686-pc-linux-gnu/libshape.a
-lm -lz
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a(chk_inside.o):
In function 'dig_point_in_area':
/home/neteler/ggg/src/libes/vect32/diglib/chk_inside.c:56: undefined
reference to 'V2_read_line'
collect2: ld returned 1 exit status
make: ***
[/home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape]
Error 1
If I change the LIBES line to
LIBES=$(VECTLIB) $(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
^^^^^^^^^^
it is compiling o.k. I guess that's not correct, somewhere a reference is
missing. Although looking at
src/CMD/generic/make.mid
I don't get an idea. Other modules having the same problem are:
./mapdev/v.build/Gmakefile
./mapdev/v.spag/Gmakefile
./mapdev/v.what/cmd/Gmakefile
Any comment is welcome!
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Markus Neteler wrote:
Hi all,
a somewhat strange thing I found in r.in.shape Gmakefile:
Using the LIBES line like that:
LIBES=$(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
I get this compilation error:
gcc -s -o
/home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape
OBJ.i686-pc-linux-gnu/main.o
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvect.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libgis.a
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvask.a -lncurses
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdatetime.a
/home/neteler/ggg/src/libes/vect32_64/shapelib-1.2.8/LIB.i686-pc-linux-gnu/libshape.a
-lm -lz
/home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a(chk_inside.o):
In function 'dig_point_in_area':
/home/neteler/ggg/src/libes/vect32/diglib/chk_inside.c:56: undefined
reference to 'V2_read_line'
collect2: ld returned 1 exit status
make: ***
[/home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape]
Error 1
If I change the LIBES line to
LIBES=$(VECTLIB) $(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
^^^^^^^^^^
it is compiling o.k. I guess that's not correct, somewhere a reference is
missing. Although looking at
src/CMD/generic/make.mid
I don't get an idea. Other modules having the same problem are:
./mapdev/v.build/Gmakefile
../mapdev/v.spag/Gmakefile
../mapdev/v.what/cmd/Gmakefile
Any comment is welcome!
Markus
I don't know how linker works but:
Note: VECTLIB = VECTLIB_REAL(Vlib) DIG2LIB(diglib)
Some functions from VECTLIB_REAL call functions from DIG2LIB
and some functions from DIG2LIB call functions from VECTLIB_REAL
In r.in.shape dig_point_in_poly() from DIG2LIB is in chk_inside.o which contains
dig_point_in_area() also which calls V2_read_line() from VECTLIB_REAL which
calls some functions from DIG2LIB.
Then LIBES must contain:
$(DIG2LIB) $(VECTLIB_REAL) $(DIG2LIB)
Radim
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Wed, Jan 03, 2001 at 08:30:58PM +0100, Radim Blazek wrote:
Markus Neteler wrote:
> Hi all,
>
> a somewhat strange thing I found in r.in.shape Gmakefile:
>
> Using the LIBES line like that:
> LIBES=$(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
>
> I get this compilation error:
> gcc -s -o
> /home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape
> OBJ.i686-pc-linux-gnu/main.o
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvect.a
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libgis.a
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libvask.a -lncurses
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdatetime.a
> /home/neteler/ggg/src/libes/vect32_64/shapelib-1.2.8/LIB.i686-pc-linux-gnu/libshape.a
> -lm -lz
> /home/neteler/ggg/src/libes/LIB.i686-pc-linux-gnu/libdig2.a(chk_inside.o):
> In function 'dig_point_in_area':
> /home/neteler/ggg/src/libes/vect32/diglib/chk_inside.c:56: undefined
> reference to 'V2_read_line'
> collect2: ld returned 1 exit status
> make: ***
> [/home/neteler/ggg/dist.i686-pc-linux-gnu/etc/bin/contrib/cmd/r.in.shape]
> Error 1
>
>
> If I change the LIBES line to
> LIBES=$(VECTLIB) $(VECTLIB) $(GISLIB) $(VASK) $(DATETIMELIB)
> ^^^^^^^^^^
>
> it is compiling o.k. I guess that's not correct, somewhere a reference is
> missing. Although looking at
> src/CMD/generic/make.mid
>
> I don't get an idea. Other modules having the same problem are:
> ./mapdev/v.build/Gmakefile
> ../mapdev/v.spag/Gmakefile
> ../mapdev/v.what/cmd/Gmakefile
>
> Any comment is welcome!
>
> Markus
I don't know how linker works but:
Note: VECTLIB = VECTLIB_REAL(Vlib) DIG2LIB(diglib)
Some functions from VECTLIB_REAL call functions from DIG2LIB
and some functions from DIG2LIB call functions from VECTLIB_REAL
In r.in.shape dig_point_in_poly() from DIG2LIB is in chk_inside.o which contains
dig_point_in_area() also which calls V2_read_line() from VECTLIB_REAL which
calls some functions from DIG2LIB.
Then LIBES must contain:
$(DIG2LIB) $(VECTLIB_REAL) $(DIG2LIB)
Hi Radim,
still I think that such double call is unusual (maybe I am wrong and it's
common). I have been posting this here to indicate that *maybe* something
referenced incorrectly within GRASS vector libs.
If you think that's o.k. then I will keep these double entries. Is that
documented somewhere?
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus
Markus Neteler wrote:
still I think that such double call is unusual (maybe I am wrong and
it's common). I have been posting this here to indicate that *maybe*
something referenced incorrectly within GRASS vector libs.
If you think that's o.k. then I will keep these double entries. Is
that documented somewhere?
It is definitely unusual, and the module did compile before. Look at
what has changed since the last version of the Gmakefile to see what is
causing the problem. Maybe we can get a hint from that.
BTW, I am currently changing all Gmakefiles that have VASK. VASK was
basically $VASKLIB $CURSES, and $CURSES was some -l stuff (eg -lncurses)
so I deleted VASK from make.mid and am changing all VASK references to
VASKLIB and adding CURSES to the compile line (just before MATHLIB).
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Thu, Jan 04, 2001 at 03:24:29PM +0700, Justin Hickey wrote:
Hi Markus
Markus Neteler wrote:
> still I think that such double call is unusual (maybe I am wrong and
> it's common). I have been posting this here to indicate that *maybe*
> something referenced incorrectly within GRASS vector libs.
> If you think that's o.k. then I will keep these double entries. Is
> that documented somewhere?
It is definitely unusual, and the module did compile before. Look at
what has changed since the last version of the Gmakefile to see what is
causing the problem. Maybe we can get a hint from that.
Well, Radim had to use a similar trick:
$(CC) $(LDFLAGS) -o $@ $(LIST) $(VECTLIB) ... $(VECTLIB_REAL) $(DIG2LIB) ...
So that's even not what it should be.
BTW, I am currently changing all Gmakefiles that have VASK. VASK was
basically $VASKLIB $CURSES, and $CURSES was some -l stuff (eg -lncurses)
so I deleted VASK from make.mid and am changing all VASK references to
VASKLIB and adding CURSES to the compile line (just before MATHLIB).
Yes, that's the correct way. Thanks for doing this job,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus
Markus Neteler wrote:
> It is definitely unusual, and the module did compile before. Look at
> what has changed since the last version of the Gmakefile to see what
> is causing the problem. Maybe we can get a hint from that.
Well, Radim had to use a similar trick:
$(CC) $(LDFLAGS) -o $@ $(LIST) $(VECTLIB) ... $(VECTLIB_REAL)
$(DIG2LIB) ...
So that's even not what it should be.
Then for now, I would recommend leaving it the way you had it. We will
have to try and find out what to do when two libraries depend on each
other.
> BTW, I am currently changing all Gmakefiles that have VASK. VASK was
> basically $VASKLIB $CURSES, and $CURSES was some -l stuff (eg
> -lncurses) so I deleted VASK from make.mid and am changing all VASK
> references to VASKLIB and adding CURSES to the compile line (just
> before MATHLIB).
Yes, that's the correct way. Thanks for doing this job,
No problem.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi all,
On Thu, Jan 04, 2001 at 03:46:10PM +0700, Justin Hickey wrote:
Hi Markus
Markus Neteler wrote:
> > It is definitely unusual, and the module did compile before. Look at
> > what has changed since the last version of the Gmakefile to see what
> > is causing the problem. Maybe we can get a hint from that.
> Well, Radim had to use a similar trick:
>
> $(CC) $(LDFLAGS) -o $@ $(LIST) $(VECTLIB) ... $(VECTLIB_REAL)
> $(DIG2LIB) ...
>
> So that's even not what it should be.
Then for now, I would recommend leaving it the way you had it. We will
have to try and find out what to do when two libraries depend on each
other.
Ok.
Finally I am using:
LIBES=$(VECTLIB) $(VECTLIB_REAL) $(DIG2LIB) $(GISLIB)...
now. This seems to be compile o.k.
Please cvs update
src/raster/r.in.shape/Gmakefile
src/mapdev/v.build/Gmakefile
src/mapdev/v.spag/Gmakefile
so, please report if anybody gets problem to compile:
gmake5 src/raster/r.in.shape/
gmake5 src/mapdev/v.build/
gmake5 src/mapdev/v.spag/
gmake5 src/mapdev/v.what/
Don't forget to remove the local OBJ.* before recompiling.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi all,
just investigated make.mid again:
BIN_MAIN_INTER = $(ETC)/bin/main/inter
BIN_MAIN_CMD = $(ETC)/bin/main/cmd
BIN_ALPHA_INTER = $(ETC)/bin/main/inter
BIN_ALPHA_CMD = $(ETC)/bin/main/cmd
BIN_CONTRIB_INTER = $(ETC)/bin/contrib/inter
BIN_CONTRIB_CMD = $(ETC)/bin/contrib/cmd
Does it make sense to support so many directories any more?
Someone already changed BIN_ALPHA_INTER from bin/alpha to
bin/main...
I propose to keep only
BIN_MAIN_INTER = $(ETC)/bin/main/inter
BIN_MAIN_CMD = $(ETC)/bin/main/cmd
and change all Gmakefiles by a script. This would simplify again
the install procedure.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus
Markus Neteler wrote:
I propose to keep only
BIN_MAIN_INTER = $(ETC)/bin/main/inter
BIN_MAIN_CMD = $(ETC)/bin/main/cmd
and change all Gmakefiles by a script. This would simplify again
the install procedure.
I agree.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Fri, Jan 05, 2001 at 10:33:12AM +0700, Justin Hickey wrote:
Hi Markus
Markus Neteler wrote:
> I propose to keep only
> BIN_MAIN_INTER = $(ETC)/bin/main/inter
> BIN_MAIN_CMD = $(ETC)/bin/main/cmd
>
> and change all Gmakefiles by a script. This would simplify again
> the install procedure.
I agree.
Maybe we again simplify that to:
BIN_INTER = $(ETC)/bin/inter
BIN_CMD = $(ETC)/bin/cmd
Or did I overlook anything?
Justin - in case of no objections to change, could your nice change script
do the job? If too much, please send the script and I'll do it next week.
Yours
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus
Markus Neteler wrote:
On Fri, Jan 05, 2001 at 10:33:12AM +0700, Justin Hickey wrote:
> Hi Markus
>
> Markus Neteler wrote:
> > I propose to keep only
> > BIN_MAIN_INTER = $(ETC)/bin/main/inter
> > BIN_MAIN_CMD = $(ETC)/bin/main/cmd
> >
> > and change all Gmakefiles by a script. This would simplify again
> > the install procedure.
>
> I agree.
Maybe we again simplify that to:
BIN_INTER = $(ETC)/bin/inter
BIN_CMD = $(ETC)/bin/cmd
Or did I overlook anything?
I don't think so. I see any problems with your suggestion.
Justin - in case of no objections to change, could your nice change
script do the job? If too much, please send the script and I'll do it
next week.
The script could almost do the job, but a human would still need to make
the changes. However, in this case, I think we can get a script to
change everything. Here's what I think would work. First change make.mid
by hand to contain only your two suggestions. Then have the script go
through all source files and change any occurance of BIN_MAIN_INTER,
BIN_MAIN_CMD, BIN_ALPHA_INTER, BIN_ALPHA_CMD, BIN_CONTRIB_INTER, or
BIN_CONTRIB_CMD to BIN_INTER or BIN_CMD. Since make.mid is the only
place where these variables are defined, it should be safe to change all
other instances since they should be only references to the variable.
What do you think?
If you agree I'll write the script and run it, probably on Monday since
it is almost dinner time here.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Ooops this should be
> Or did I overlook anything?
I don't think so. I see any problems with your suggestion.
^
don't
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Markus,
i would vote for the below change.
But we should check if there are programs that rely on the old paths.
I remember that at least for tcltkgrass some programs use hard-coded
paths. I recall that some man-generation program used the alpha/main
classification for a footer, but that may have changed with the new
man-system.
Perhaps some grep'ping can help.
cu,
Andreas
Markus Neteler wrote:
On Fri, Jan 05, 2001 at 10:33:12AM +0700, Justin Hickey wrote:
> Hi Markus
>
> Markus Neteler wrote:
> > I propose to keep only
> > BIN_MAIN_INTER = $(ETC)/bin/main/inter
> > BIN_MAIN_CMD = $(ETC)/bin/main/cmd
> >
> > and change all Gmakefiles by a script. This would simplify again
> > the install procedure.
>
> I agree.
Maybe we again simplify that to:
BIN_INTER = $(ETC)/bin/inter
BIN_CMD = $(ETC)/bin/cmd
Or did I overlook anything?
Justin - in case of no objections to change, could your nice change script
do the job? If too much, please send the script and I'll do it next week.
Yours
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Andreas
Andreas Lange wrote:
But we should check if there are programs that rely on the old paths.
I remember that at least for tcltkgrass some programs use hard-coded
paths. I recall that some man-generation program used the alpha/main
classification for a footer, but that may have changed with the new
man-system.
Perhaps some grep'ping can help.
Yep, my script does some grep'ping to try and find all occurrances of
what I'm looking for, but there is a possibility I might miss a few. But
they should pop up on testing and hopefully be very few in number.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'