[GRASSLIST:5915] 6.0.0beta2 configure failure

   I seem stuck in an infinite loop here. Two problems configuring the build:

   1) For some reason, the script cannot locate the readline library (which
is installed). Is readline necessary for this version? If so, should I
specify /usr/lib as the path on the --with-readline line?

   2) The serious problem is that building GRASS with gdal support wants the
gdal path. But, building gdal with GRASS support wants the GRASS path.
Something's gotta' give. What are folks doing about this lock condition?

Thanks,

Rich

--
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On Sat, 26 Feb 2005, Rich Shepard wrote:

I seem stuck in an infinite loop here. Two problems configuring the build:

1) For some reason, the script cannot locate the readline library (which
is installed). Is readline necessary for this version? If so, should I
specify /usr/lib as the path on the --with-readline line?

   Found the answer to this in ./configure.

   However, despite installing fftw-3.0.1 the configure script will not find
the proper libraries. So I disabled this feature.

Rich

--
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

Rich,

I suggest you familiarize yourself with searching through the grasslist archives. In there you will find references to both your problems. To include support for readline, you must link in the ncurses library manually, at least on linux with the gnu compilers. There are examples in the archive as to how you do that. Regarding fftw, you must use a version prior to v. 3.x, at least at this time.

Lastly, its not so much that configure can't find needed libraries as it is that the configure process cannot find the proper symbols it needs in the library.

-jv

Rich Shepard wrote:

On Sat, 26 Feb 2005, Rich Shepard wrote:

I seem stuck in an infinite loop here. Two problems configuring the build:

1) For some reason, the script cannot locate the readline library (which
is installed). Is readline necessary for this version? If so, should I
specify /usr/lib as the path on the --with-readline line?

  Found the answer to this in ./configure.

  However, despite installing fftw-3.0.1 the configure script will not find
the proper libraries. So I disabled this feature.

Rich

   I seem stuck in an infinite loop here. Two problems configuring the
   build:

   1) For some reason, the script cannot locate the readline library
   (which
is installed). Is readline necessary for this version? If so, should I
specify /usr/lib as the path on the --with-readline line?

Redhat/Fedora? there is a problem there.
Missing readline isn't a big deal, only used by r.mapcalc I think.
Don't worry about it, just leave off --with-readline.
see http://article.gmane.org/gmane.comp.gis.grass.user/1000
/usr/lib (or anything in /etc/ld.co.conf) is default search path.

   2) The serious problem is that building GRASS with gdal support
   wants the
gdal path. But, building gdal with GRASS support wants the GRASS path.
Something's gotta' give. What are folks doing about this lock
condition?

Build GDAL without GRASS support. This is for when you would like GDAL
to read GRASS maps without actually having GRASS installed. You can
compile the plugin later if needed (eg for QGIS or Mapserver).

However, despite installing fftw-3.0.1 the configure script will not
find the proper libraries. So I disabled this feature.

GRASS requires fftw 2.x not 3.x, until we have a volunteer to update the
code. see REQUIREMENTS.html.

In general, look at the end of config.log to see what the exact problems
are.

Hamish

On Mon, Feb 28, 2005 at 10:11:37AM +1300, we recorded a bogon-computron collision of the <hamish_nospam@yahoo.com> flavor, containing:

> 2) The serious problem is that building GRASS with gdal support
> wants the
> gdal path. But, building gdal with GRASS support wants the GRASS path.
> Something's gotta' give. What are folks doing about this lock
> condition?

Build GDAL without GRASS support. This is for when you would like GDAL
to read GRASS maps without actually having GRASS installed. You can
compile the plugin later if needed (eg for QGIS or Mapserver).

I'm told that r.out.gdal complains if GDAL is compiled without GRASS support.

It should be enough to first build GDAL without GRASS support, then build GRASS
with GDAL support, then rebuild and install GDAL *with* GRASS support by
pointing the configure script at your installed GRASS binaries directory. The
shared library should then be OK, and r.out.gdal should work without
recompiling GRASS.

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"When life gives you lemons, find someone with a paper cut."

On Mon, 28 Feb 2005, Hamish wrote:

Redhat/Fedora? there is a problem there.

   No. Slackware.

Missing readline isn't a big deal, only used by r.mapcalc I think. Don't
worry about it, just leave off --with-readline. see

   Well, mapcalc is important. And, I got this fixed by using the
--with-readline option. Without explicit instructions the build couldn't
find it.

Build GDAL without GRASS support. This is for when you would like GDAL to
read GRASS maps without actually having GRASS installed. You can compile
the plugin later if needed (eg for QGIS or Mapserver).

   That's what I did. And thank you for explaing what function the GRASS
support serves in GDAL.

GRASS requires fftw 2.x not 3.x, until we have a volunteer to update the
code. see REQUIREMENTS.html.

   I missed that. Don't do satellite imagery much anyway.

In general, look at the end of config.log to see what the exact problems
are.

   Forgot about this, too.

Thanks,

Rich

--
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

On Sun, 27 Feb 2005, Tom Russo wrote:

It should be enough to first build GDAL without GRASS support, then build
GRASS with GDAL support, then rebuild and install GDAL *with* GRASS
support by pointing the configure script at your installed GRASS binaries
directory. The shared library should then be OK, and r.out.gdal should
work without recompiling GRASS.

Tom,

   I thought of doing this but have not yet done so.

Thanks,

Rich

--
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

> Missing readline isn't a big deal, only used by r.mapcalc I think.
> Don't worry about it, just leave off --with-readline. see

   Well, mapcalc is important. And, I got this fixed by using the
--with-readline option. Without explicit instructions the build
couldn't find it.

for the record: r.mapcalc will still build without readline, just
without readline support.

Hamish

Hamish wrote:

Redhat/Fedora? there is a problem there.

Could you point me to more particulars about Fedora problems?
That's what I'm using (FC3), and I still have some problems I haven't
solved. The program compiles, installs and appears to run at least
as far as the GUI appearing on screen, but I haven't got any data to
load yet.

david

>Redhat/Fedora? there is a problem there.
>
Could you point me to more particulars about Fedora problems?

That was just a Redhat 9 problem with locating readline during the
configure step. Not a big deal; otherwise Redhat/Fedora works just fine.

> see http://article.gmane.org/gmane.comp.gis.grass.user/1000

That's what I'm using (FC3), and I still have some problems I haven't
solved. The program compiles, installs and appears to run at least
as far as the GUI appearing on screen, but I haven't got any data to
load yet.

Can you give a more detailed description of your problem?

- do you have any data?
- can you get import it in GRASS?
- are you just not sure how to display it?

Try starting with a tutorial:
  http://grass.gdf-hannover.de/twiki/bin/view/GRASS/WebHome

Hamish

Platform Fedora FC1 x86

GRASS 6.0.0beta2:~/GIS/ND/DEM > r.in.gdal input=fargo_e.dem
output=fargo_e
A datum name nad27 (North_American_Datum_1927) was specified without
transformation parameters.
WARNING: Non-interactive mode: the GRASS default for nad27 is
         towgs84=-22.000,157.000,176.000.
Projection of input dataset and current location appear to match.
Proceeding with import...
Segmentation fault

File is one of many all others import just fine.

File can be obtained at

http://gis1.state.nd.us/250k/dem

Filename

fargo_e.zip

Suggestions ?

-pete