[GRASS-dev] problems compiling GRASS 6.3 cvs on Mac

cmbarton · October 21, 2007, 12:00am

William,

I just tried to update and compile GRASS 6.3 on my Mactel MacBook. (I did a make distclean first)

I had the usual d.m error, but also can’t compile r.out.tiff.

Here is the error:

cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$ make
gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/lib -o /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/bin/r.out.tiff OBJ.i686-apple-darwin8.10.3/r.out.tiff.o -lgrass_gis -lgrass_datetime -lz -ltiff -lz
/usr/bin/ld: can’t locate file for: -ltiff
collect2: ld returned 1 exit status
make: *** [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/bin/r.out.tiff] Error 1
cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$

I had no problem with configure. I’m downloading a new all frameworks to see if I’m missing anything new and then will compile again. (Any chance you could put a date on these in your site so it would be clear which, if any have been updated recently?)

Michael

Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

William_Kyngesburye · October 21, 2007, 12:24am

Hehe, I just had the same minutes ago... From the link command, I see that the libtiff dir is not included:

gcc -L/Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-darwin8.10.1/lib -arch ppc -arch i386 -arch ppc -arch i386 -L/usr/local/pgsql/lib -o /Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-darwin8.10.1/bin/r.out.tiff OBJ.i686-apple-darwin8.10.1/r.out.tiff.o -lgrass_gis -lgrass_datetime -lz -ltiff -lz

I think the recent makefile cleanup may have triggered a problem with the r.out.tiff makefile. It seems that EXTRA_CFLAGS is no longer added to link commands (which makes sense). But the r.out.tiff makefile doesn't add the libtiff path to LIBES:

LIBES = $(GISLIB) $(TIFFLIB)

It should probably be (indeed, this fixes it for me):

LIBES = $(GISLIB) $(TIFFLIBPATH) $(TIFFLIB)

(And TIFFLIBPATH should be removed from EXTRA_CFLAGS)

On Oct 20, 2007, at 7:00 PM, Michael Barton wrote:

William,

I just tried to update and compile GRASS 6.3 on my Mactel MacBook. (I did a make distclean first)

I had the usual d.m error, but also can't compile r.out.tiff.

Here is the error:

cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$ make
gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/lib -o /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/bin/r.out.tiff OBJ.i686-apple-darwin8.10.3/r.out.tiff.o -lgrass_gis -lgrass_datetime -lz -ltiff -lz
/usr/bin/ld: can't locate file for: -ltiff
collect2: ld returned 1 exit status
make: *** [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/bin/r.out.tiff] Error 1
cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$

I had no problem with configure. I'm downloading a new all frameworks to see if I'm missing anything new and then will compile again. (Any chance you could put a date on these in your site so it would be clear which, if any have been updated recently?)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

cmbarton · October 21, 2007, 12:34am

Yup. Fixed it for me too.

Michael

On 10/20/07 5:24 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

Hehe, I just had the same minutes ago... From the link command, I
see that the libtiff dir is not included:

gcc -L/Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-darwin8.10.1/
lib -arch ppc -arch i386 -arch ppc -arch i386 -L/usr/local/pgsql/
lib -o /Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-
darwin8.10.1/bin/r.out.tiff OBJ.i686-apple-darwin8.10.1/r.out.tiff.o
-lgrass_gis -lgrass_datetime -lz -ltiff -lz

I think the recent makefile cleanup may have triggered a problem with
the r.out.tiff makefile. It seems that EXTRA_CFLAGS is no longer
added to link commands (which makes sense). But the r.out.tiff
makefile doesn't add the libtiff path to LIBES:

LIBES = $(GISLIB) $(TIFFLIB)

It should probably be (indeed, this fixes it for me):

LIBES = $(GISLIB) $(TIFFLIBPATH) $(TIFFLIB)

(And TIFFLIBPATH should be removed from EXTRA_CFLAGS)

On Oct 20, 2007, at 7:00 PM, Michael Barton wrote:

William,

I just tried to update and compile GRASS 6.3 on my Mactel MacBook.
(I did a make distclean first)

I had the usual d.m error, but also can't compile r.out.tiff.

Here is the error:

cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$ make
gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.10.3/
lib -o /Users/cmbarton/grass_dev/grass6/dist.i686-apple-
darwin8.10.3/bin/r.out.tiff OBJ.i686-apple-darwin8.10.3/
r.out.tiff.o -lgrass_gis -lgrass_datetime -lz -ltiff -lz
/usr/bin/ld: can't locate file for: -ltiff
collect2: ld returned 1 exit status
make: *** [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-
darwin8.10.3/bin/r.out.tiff] Error 1
cmb-MBP-2:~/grass_dev/grass6/raster/r.out.tiff cmbarton$

I had no problem with configure. I'm downloading a new all
frameworks to see if I'm missing anything new and then will compile
again. (Any chance you could put a date on these in your site so it
would be clear which, if any have been updated recently?)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Glynn_Clements1 · October 21, 2007, 1:57am

William Kyngesburye wrote:

Hehe, I just had the same minutes ago... From the link command, I
see that the libtiff dir is not included:

gcc -L/Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-darwin8.10.1/
lib -arch ppc -arch i386 -arch ppc -arch i386 -L/usr/local/pgsql/
lib -o /Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-
darwin8.10.1/bin/r.out.tiff OBJ.i686-apple-darwin8.10.1/r.out.tiff.o
-lgrass_gis -lgrass_datetime -lz -ltiff -lz

I think the recent makefile cleanup may have triggered a problem with
the r.out.tiff makefile. It seems that EXTRA_CFLAGS is no longer
added to link commands (which makes sense). But the r.out.tiff
makefile doesn't add the libtiff path to LIBES:

LIBES = $(GISLIB) $(TIFFLIB)

It should probably be (indeed, this fixes it for me):

LIBES = $(GISLIB) $(TIFFLIBPATH) $(TIFFLIB)

(And TIFFLIBPATH should be removed from EXTRA_CFLAGS)

Fixed in CVS.

--
Glynn Clements <glynn@gclements.plus.com>

cmbarton · October 21, 2007, 7:51pm

Thanks Glynn.

Michael

On 10/20/07 6:57 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

William Kyngesburye wrote:

Hehe, I just had the same minutes ago... From the link command, I
see that the libtiff dir is not included:

gcc -L/Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-darwin8.10.1/
lib -arch ppc -arch i386 -arch ppc -arch i386 -L/usr/local/pgsql/
lib -o /Users/Shared/src/GRASS/cvs/grass6/dist.i686-apple-
darwin8.10.1/bin/r.out.tiff OBJ.i686-apple-darwin8.10.1/r.out.tiff.o
-lgrass_gis -lgrass_datetime -lz -ltiff -lz

I think the recent makefile cleanup may have triggered a problem with
the r.out.tiff makefile. It seems that EXTRA_CFLAGS is no longer
added to link commands (which makes sense). But the r.out.tiff
makefile doesn't add the libtiff path to LIBES:

LIBES = $(GISLIB) $(TIFFLIB)

It should probably be (indeed, this fixes it for me):

LIBES = $(GISLIB) $(TIFFLIBPATH) $(TIFFLIB)

(And TIFFLIBPATH should be removed from EXTRA_CFLAGS)

Fixed in CVS.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Glynn_Clements1 · October 23, 2007, 6:40pm

Helena Mitasova wrote:

it is almost working now. It is only the nan value that is still causing
problems - you were right that the computation was correctly done for
most of the area but because of the nan value the color table was not
set correctly and the resulting map was plain white.
I have an area in the series that is set to zero (ocean level) so those
are the identical values where I am getting 0/0=nan. I can imagine other
situations where this can happen so it would be good to change the nan
result to null.

I've added the following change to CVS, which should catch NaNs:

--- lib/stats/c_reg.c~ 2007-10-23 13:33:32.000000000 +0100
+++ lib/stats/c_reg.c 2007-10-23 19:34:29.000000000 +0100
@@ -70,6 +70,10 @@
     G_set_d_null_value(result, 1);
     break;
   }
+
+ /* Check for NaN */
+ if (*result != *result)
+ G_set_d_null_value(result, 1);
}

void c_reg_m(DCELL *result, DCELL *values, int n)
@@ -153,6 +157,10 @@
     G_set_d_null_value(result, 1);
     break;
   }
+
+ /* Check for NaN */
+ if (*result != *result)
+ G_set_d_null_value(result, 1);
}

void w_reg_m(DCELL *result, DCELL (*values)[2], int n)

I still have no idea if the actual calculation is correct, or even
*which* coefficient it's calculating.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn_Clements1 · October 23, 2007, 8:43pm

Glynn Clements wrote:

> it is almost working now. It is only the nan value that is still causing
> problems - you were right that the computation was correctly done for
> most of the area but because of the nan value the color table was not
> set correctly and the resulting map was plain white.
> I have an area in the series that is set to zero (ocean level) so those
> are the identical values where I am getting 0/0=nan. I can imagine other
> situations where this can happen so it would be good to change the nan
> result to null.

I've added the following change to CVS, which should catch NaNs:

--- lib/stats/c_reg.c~ 2007-10-23 13:33:32.000000000 +0100
+++ lib/stats/c_reg.c 2007-10-23 19:34:29.000000000 +0100
@@ -70,6 +70,10 @@
     G_set_d_null_value(result, 1);
     break;
   }
+
+ /* Check for NaN */
+ if (*result != *result)
+ G_set_d_null_value(result, 1);
}

void c_reg_m(DCELL *result, DCELL *values, int n)
@@ -153,6 +157,10 @@
     G_set_d_null_value(result, 1);
     break;
   }
+
+ /* Check for NaN */
+ if (*result != *result)
+ G_set_d_null_value(result, 1);
}

void w_reg_m(DCELL *result, DCELL (*values)[2], int n)

What I forgot to add (and the reason I CC'd to grass-dev), is that
G_is_[fd]_null_value() should probably check for any IEEE NaN, rather
than for a specific bit pattern.

I initially thought about adding such a check to the raster I/O code,
but that doesn't account for cases where nulls are tested for within
the module which generates them.

The main question is whether such a change should be made in 6.3 or
reserved for 7.x.

--
Glynn Clements <glynn@gclements.plus.com>