Hello, I'm trying to recompile Grass and encountering problems. Hopefully someone can help.
I'm running Fedora Core 4, and have successfully (I think - no testing yet) compiled Grass 6.0.1 in the past. I did an update on the OS, and fftw2 was replaced with fftw3. Now Grass won't run because it can'f find fftw2, and it won't recompile because configure is looking for fftw2 and/or GDALOpen. They appear to be related...
The last five lines of config output are:
checking whether to use GDAL... yes
checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
configure: error: *** Unable to locate GDAL library.
The references to fftw2 are in the config.log near the end. Here's the section starting where it looks for gdal:
configure:7059: checking whether to use GDAL
configure:7073: checking for gdal-config
configure:7131: checking for GDALOpen
configure:7157: gcc -o conftest -g -O2 -Wl,--export-dynamic conftest.c -L/usr/local/lib -lgda
l 1>&5
/usr/bin/ld: warning: libfftw.so.2, needed by /usr/local/grass-6.0.1/lib/libgrass_I.so, not foun
d (try using -rpath or -rpath-link)
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to `fftw2d_create_plan'
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to `fftwnd_destroy_plan'
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to `fftwnd_one'
collect2: ld returned 1 exit status
configure: failed program was:
#line 7134 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char GDALOpen(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char GDALOpen();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_GDALOpen) || defined (__stub___GDALOpen)
choke me
#else
GDALOpen();
#endif
; return 0; }
configure:7176: checking for GDALOpen
configure:7202: gcc -o conftest -g -O2 -Wl,--export-dynamic conftest.c -L/usr/local/lib -lgeo
s -ljpeg -ltiff -lpng -L/usr/local/grass-6.0.1//lib -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgras
s_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I -lgrass_gproj -lgrass_vask -
lgrass_gmath -lgrass_gis -lgrass_datetime -L/usr/lib -lpq -lz -lm -lrt -ldl -L/usr/bin/lib -lsql
ite3 -L/usr/local/lib -lgdal 1>&5
/usr/bin/ld: warning: libfftw.so.2, needed by /usr/local/grass-6.0.1//lib/libgrass_I.so, not fou
nd (try using -rpath or -rpath-link)
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to `fftw2d_create_plan'
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to `fftwnd_destroy_plan'
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to `fftwnd_one'
collect2: ld returned 1 exit status
configure: failed program was:
#line 7179 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char GDALOpen(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char GDALOpen();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_GDALOpen) || defined (__stub___GDALOpen)
choke me
#else
GDALOpen();
#endif
; return 0; }
(END)
Michael,
you need (as written below), the FFT2. GRASS does not
work with FFT3.
Markus
On Sun, Feb 12, 2006 at 11:26:28AM -0800, Michael Rensing wrote:
Hello, I'm trying to recompile Grass and encountering problems.
Hopefully someone can help.
I'm running Fedora Core 4, and have successfully (I think - no testing
yet) compiled Grass 6.0.1 in the past. I did an update on the OS, and
fftw2 was replaced with fftw3. Now Grass won't run because it can'f find
fftw2, and it won't recompile because configure is looking for fftw2
and/or GDALOpen. They appear to be related...
The last five lines of config output are:
checking whether to use GDAL... yes
checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** Unable to locate GDAL library.
The references to fftw2 are in the config.log near the end. Here's the
section starting where it looks for gdal:
configure:7059: checking whether to use GDAL
configure:7073: checking for gdal-config
configure:7131: checking for GDALOpen
configure:7157: gcc -o conftest -g -O2 -Wl,--export-dynamic
conftest.c -L/usr/local/lib -lgda
l 1>&5
/usr/bin/ld: warning: libfftw.so.2, needed by
/usr/local/grass-6.0.1/lib/libgrass_I.so, not foun
d (try using -rpath or -rpath-link)
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to
`fftw2d_create_plan'
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to
`fftwnd_destroy_plan'
/usr/local/grass-6.0.1/lib/libgrass_gmath.so: undefined reference to
`fftwnd_one'
collect2: ld returned 1 exit status
configure: failed program was:
#line 7134 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char GDALOpen(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char GDALOpen();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_GDALOpen) || defined (__stub___GDALOpen)
choke me
#else
GDALOpen();
#endif
; return 0; }
configure:7176: checking for GDALOpen
configure:7202: gcc -o conftest -g -O2 -Wl,--export-dynamic
conftest.c -L/usr/local/lib -lgeo
s -ljpeg -ltiff -lpng -L/usr/local/grass-6.0.1//lib -lgrass_vect
-lgrass_dig2 -lgrass_dgl -lgras
s_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I
-lgrass_gproj -lgrass_vask -
lgrass_gmath -lgrass_gis -lgrass_datetime -L/usr/lib -lpq -lz -lm -lrt
-ldl -L/usr/bin/lib -lsql
ite3 -L/usr/local/lib -lgdal 1>&5
/usr/bin/ld: warning: libfftw.so.2, needed by
/usr/local/grass-6.0.1//lib/libgrass_I.so, not fou
nd (try using -rpath or -rpath-link)
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to
`fftw2d_create_plan'
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to
`fftwnd_destroy_plan'
/usr/local/grass-6.0.1//lib/libgrass_gmath.so: undefined reference to
`fftwnd_one'
collect2: ld returned 1 exit status
configure: failed program was:
#line 7179 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char GDALOpen(); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char GDALOpen();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_GDALOpen) || defined (__stub___GDALOpen)
choke me
#else
GDALOpen();
#endif
; return 0; }
(END)
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
Michael Rensing wrote:
Hello, I'm trying to recompile Grass and encountering problems.
Hopefully someone can help.
I'm running Fedora Core 4, and have successfully (I think - no testing
yet) compiled Grass 6.0.1 in the past. I did an update on the OS, and
fftw2 was replaced with fftw3. Now Grass won't run because it can'f find
fftw2, and it won't recompile because configure is looking for fftw2
and/or GDALOpen. They appear to be related...
You need to configure GRASS using --without-fftw if you don't have
FFTW 2.x.
If your GDAL library was built with GRASS support, and you no longer
have a working version of GRASS, you will need to first build GDAl
without GRASS support before you can build GRASS. If you wish, you can
re-build GDAL with GRASS support once you have built GRASS.
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Feb 13, 2006 at 03:39:37PM +0000, Glynn Clements wrote:
Michael Rensing wrote:
...
You need to configure GRASS using --without-fftw if you don't have
FFTW 2.x.
If your GDAL library was built with GRASS support, and you no longer
have a working version of GRASS, you will need to first build GDAl
without GRASS support before you can build GRASS. If you wish, you can
re-build GDAL with GRASS support once you have built GRASS.
Michael,
this is explained in detail here:
http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassQgisGdalOgrPlugin
Markus
Thanks everyone. I buess I was fooled into thinking that fftw3 would replace fftw2 in all cases when yum update automagically replaced it. I'll see if I can re-install fftw2.
Has anyone got a quick explanation why the two versions of fftw are not compatible?
Also, thanks for the link on GRASS and GDAL. I'm still having trouble finding all the information resources on GRASS, so every bit helps.
Michael
Markus Neteler wrote:
On Mon, Feb 13, 2006 at 03:39:37PM +0000, Glynn Clements wrote:
Michael Rensing wrote:
...
You need to configure GRASS using --without-fftw if you don't have
FFTW 2.x.
If your GDAL library was built with GRASS support, and you no longer
have a working version of GRASS, you will need to first build GDAl
without GRASS support before you can build GRASS. If you wish, you can
re-build GDAL with GRASS support once you have built GRASS.
Michael,
this is explained in detail here:
http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassQgisGdalOgrPlugin
Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Michael Rensing wrote:
Thanks everyone. I buess I was fooled into thinking that fftw3 would
replace fftw2 in all cases when yum update automagically replaced it.
I'll see if I can re-install fftw2.
Has anyone got a quick explanation why the two versions of fftw are not
compatible?
According to the FFTW FAQ:
Question 3.1. Why not support the FFTW 2 interface in FFTW 3?
FFTW 3 has semantics incompatible with earlier versions: its plans can
only be used for a given stride, multiplicity, and other
characteristics of the input and output arrays; these stronger
semantics are necessary for performance reasons. Thus, it is
impossible to efficiently emulate the older interface (whose plans can
be used for any transform of the same size). We believe that it should
be possible to upgrade most programs without any difficulty, however.
Note that the FFT functionality in GRASS creates a new plan for each
transform and discards it afterwards, so it would be a simple matter
to update lib/gmath/fft.c to use the FFTW v3 API instead.
Supporting both versions of the API would require more work, most of
which would be changes the configuration and build system.
--
Glynn Clements <glynn@gclements.plus.com>
For anyone running into this on FC4, the fftw package automatically updated from version 2 to version 3 when I used yum update, but now there's an fftw2 and fftw2-devel package.
M
Glynn Clements wrote:
Michael Rensing wrote:
Thanks everyone. I buess I was fooled into thinking that fftw3 would replace fftw2 in all cases when yum update automagically replaced it. I'll see if I can re-install fftw2.
Has anyone got a quick explanation why the two versions of fftw are not compatible?
According to the FFTW FAQ:
Question 3.1. Why not support the FFTW 2 interface in FFTW 3?
FFTW 3 has semantics incompatible with earlier versions: its plans can
only be used for a given stride, multiplicity, and other
characteristics of the input and output arrays; these stronger
semantics are necessary for performance reasons. Thus, it is
impossible to efficiently emulate the older interface (whose plans can
be used for any transform of the same size). We believe that it should
be possible to upgrade most programs without any difficulty, however.
Note that the FFT functionality in GRASS creates a new plan for each
transform and discards it afterwards, so it would be a simple matter
to update lib/gmath/fft.c to use the FFTW v3 API instead.
Supporting both versions of the API would require more work, most of
which would be changes the configuration and build system.