[GRASS-user] Grass62 on X86_64

GRASS GRASS user
,
1

I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
just pulled off the i386 rpms and installed those, but discovered that
they were NOT compiled with postgresql support for some reason. While I
don't mind compiling grass62 again with this support, the problem is
that the installed support libraries (gdal, proj, etc) are only for
i386... This is leading to all sorts of problems. How to find these
libraries for x86_64, etc...

Given that there are many other things I would rather be doing and need
to do than screw around with this, what's the fastest, easiest solution
here?

thanks
Craig

2

On Mon, 2007-02-12 at 15:31 -0700, Craig Aumann wrote:

I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
just pulled off the i386 rpms and installed those, but discovered that
they were NOT compiled with postgresql support for some reason. While I
don't mind compiling grass62 again with this support, the problem is
that the installed support libraries (gdal, proj, etc) are only for
i386... This is leading to all sorts of problems. How to find these
libraries for x86_64, etc...

The i386 binaries will run fine, but I don't like to muck up my x86_64
system with i386 packages, either.

For FC6, the easiest method is to use yum and grab the following
packages (and dependencies):
proj-devel
geos-devel
libpng-devel
libjpeg-devel
tcl-devel
freetype2-devel
ncurses-devel
libtiff-devel
libX11-devel
fftw2-devel

There may be others, I'm forgetting.

You will also need to get the source for gdal and compile that as well.
You'll also need development libraries for any file formats you'd like
to work with as well.

As you can tell, this isn't for the faint of heart. I haven't had any
requests for x86_64 FC binaries, so I haven't built them. If I get a
few more, I'll build them for the next stable release.

Given that there are many other things I would rather be doing and need
to do than screw around with this, what's the fastest, easiest solution
here?

Ditto.

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

3

Ok, this is what I want to avoid, because its a pain in the ass and I
don't have time for it.

Is there a i386 grass rpm package with postgresql support in it?

Thanks

On Mon, 2007-02-12 at 15:04 -0800, Brad Douglas wrote:

On Mon, 2007-02-12 at 15:31 -0700, Craig Aumann wrote:
> I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
> just pulled off the i386 rpms and installed those, but discovered that
> they were NOT compiled with postgresql support for some reason. While I
> don't mind compiling grass62 again with this support, the problem is
> that the installed support libraries (gdal, proj, etc) are only for
> i386... This is leading to all sorts of problems. How to find these
> libraries for x86_64, etc...

The i386 binaries will run fine, but I don't like to muck up my x86_64
system with i386 packages, either.

For FC6, the easiest method is to use yum and grab the following
packages (and dependencies):
proj-devel
geos-devel
libpng-devel
libjpeg-devel
tcl-devel
freetype2-devel
ncurses-devel
libtiff-devel
libX11-devel
fftw2-devel

There may be others, I'm forgetting.

You will also need to get the source for gdal and compile that as well.
You'll also need development libraries for any file formats you'd like
to work with as well.

As you can tell, this isn't for the faint of heart. I haven't had any
requests for x86_64 FC binaries, so I haven't built them. If I get a
few more, I'll build them for the next stable release.

> Given that there are many other things I would rather be doing and need
> to do than screw around with this, what's the fastest, easiest solution
> here?

Ditto.

4

Craig Aumann napisa³(a):

I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
just pulled off the i386 rpms and installed those, but discovered that
they were NOT compiled with postgresql support for some reason. While I
don't mind compiling grass62 again with this support, the problem is
that the installed support libraries (gdal, proj, etc) are only for
i386... This is leading to all sorts of problems. How to find these
libraries for x86_64, etc...

Given that there are many other things I would rather be doing and need
to do than screw around with this, what's the fastest, easiest solution
here?

thanks
Craig

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
  

generally, gdal and proj are very easy to compile on 64 bit architecture. Simply compile these libraries insted of installing them from packages
J.

5

Brad,

We had enough problems building GRASS on FC6 that Markus had to help us by
directly logging into the machine. It turned out to be a very minor issue,
but infuriatingly difficult to find. Probably a growing number of people are
in the process of upgrading to FC6 so I'd like to add my vote for a binary
when you have time.

Michael

On 2/12/07 4:04 PM, "Brad Douglas" <rez@touchofmadness.com> wrote:

On Mon, 2007-02-12 at 15:31 -0700, Craig Aumann wrote:

I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
just pulled off the i386 rpms and installed those, but discovered that
they were NOT compiled with postgresql support for some reason. While I
don't mind compiling grass62 again with this support, the problem is
that the installed support libraries (gdal, proj, etc) are only for
i386... This is leading to all sorts of problems. How to find these
libraries for x86_64, etc...

The i386 binaries will run fine, but I don't like to muck up my x86_64
system with i386 packages, either.

For FC6, the easiest method is to use yum and grab the following
packages (and dependencies):
proj-devel
geos-devel
libpng-devel
libjpeg-devel
tcl-devel
freetype2-devel
ncurses-devel
libtiff-devel
libX11-devel
fftw2-devel

There may be others, I'm forgetting.

You will also need to get the source for gdal and compile that as well.
You'll also need development libraries for any file formats you'd like
to work with as well.

As you can tell, this isn't for the faint of heart. I haven't had any
requests for x86_64 FC binaries, so I haven't built them. If I get a
few more, I'll build them for the next stable release.

Given that there are many other things I would rather be doing and need
to do than screw around with this, what's the fastest, easiest solution
here?

Ditto.

__________________________________________
Michael Barton, Professor of Anthropology
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

6

On Tue, 2007-02-13 at 07:45 -0700, Michael Barton wrote:

Brad,

We had enough problems building GRASS on FC6 that Markus had to help us by
directly logging into the machine. It turned out to be a very minor issue,
but infuriatingly difficult to find. Probably a growing number of people are
in the process of upgrading to FC6 so I'd like to add my vote for a binary
when you have time.

Okay. I'll try to throw something together for the 6.3 preview. There
won't be PostgreSQL support unless I can find a way to make it
completely modular. Then again, I have noticed that the PGSQL backend
is becoming increasingly popular as a default installation.

Comments on PGSQL support?

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

7

We don't use it.

If anything, I'd probably use SQLITE.

Michael

On 2/14/07 10:58 AM, "Brad Douglas" <rez@touchofmadness.com> wrote:

On Tue, 2007-02-13 at 07:45 -0700, Michael Barton wrote:

Brad,

We had enough problems building GRASS on FC6 that Markus had to help us by
directly logging into the machine. It turned out to be a very minor issue,
but infuriatingly difficult to find. Probably a growing number of people are
in the process of upgrading to FC6 so I'd like to add my vote for a binary
when you have time.

Okay. I'll try to throw something together for the 6.3 preview. There
won't be PostgreSQL support unless I can find a way to make it
completely modular. Then again, I have noticed that the PGSQL backend
is becoming increasingly popular as a default installation.

Comments on PGSQL support?

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

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

8

Craig,

The issue is dependencies. We already have a large number of
dependencies (as you have noticed). Requiring another very large
dependency is an issue, nor do I have the resources to create 5
different versions to accommodate each and every user (someone may want
Jasper, or Kakadu, or ECW...Sadly, we can't be all things to all people
with the current architecture). Also, keep in mind that most of us are
not compensated for our work. We are all volunteers here.

1 for and 1 against. Others?

Let's open this up to i386, too, since I also build RPMs for that
architecture as well.

On Wed, 2007-02-14 at 12:09 -0700, Craig Aumann wrote:

Well, I certainly use POSTGRESQL... I don't understand the issues
involved in modularizing it, or why it can't be compiled in by default
without effecting endusers... I guess the bigger issue is that GRASS is
supposed to support a variety of databases, and it would be nice if it
simply did this without the end user having to muck about with
recompilling.

> On Tue, 2007-02-13 at 07:45 -0700, Michael Barton wrote:
>> Brad,
>>
>> We had enough problems building GRASS on FC6 that Markus had to help us
>> by
>> directly logging into the machine. It turned out to be a very minor
>> issue,
>> but infuriatingly difficult to find. Probably a growing number of people
>> are
>> in the process of upgrading to FC6 so I'd like to add my vote for a
>> binary
>> when you have time.
>
> Okay. I'll try to throw something together for the 6.3 preview. There
> won't be PostgreSQL support unless I can find a way to make it
> completely modular. Then again, I have noticed that the PGSQL backend
> is becoming increasingly popular as a default installation.
>
> Comments on PGSQL support?

--
Brad Douglas <rez touchofmadness com> KB8UYR/6
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785

9

Your points are good ones, given that GRASS (unlike most other
applications) depends on SO many other apps. Unfortunately, I have no sage
suggestions.

Craig

Craig,

The issue is dependencies. We already have a large number of
dependencies (as you have noticed). Requiring another very large
dependency is an issue, nor do I have the resources to create 5
different versions to accommodate each and every user (someone may want
Jasper, or Kakadu, or ECW...Sadly, we can't be all things to all people
with the current architecture). Also, keep in mind that most of us are
not compensated for our work. We are all volunteers here.

1 for and 1 against. Others?

Let's open this up to i386, too, since I also build RPMs for that
architecture as well.

On Wed, 2007-02-14 at 12:09 -0700, Craig Aumann wrote:

Well, I certainly use POSTGRESQL... I don't understand the issues
involved in modularizing it, or why it can't be compiled in by default
without effecting endusers... I guess the bigger issue is that GRASS
is
supposed to support a variety of databases, and it would be nice if it
simply did this without the end user having to muck about with
recompilling.

> On Tue, 2007-02-1

10

Brad Douglas wrote:

> We had enough problems building GRASS on FC6 that Markus had to help us by
> directly logging into the machine. It turned out to be a very minor issue,
> but infuriatingly difficult to find. Probably a growing number of people are
> in the process of upgrading to FC6 so I'd like to add my vote for a binary
> when you have time.

Okay. I'll try to throw something together for the 6.3 preview. There
won't be PostgreSQL support unless I can find a way to make it
completely modular.

AFAICT, that shouldn't be an issue any more.

When I made the Cygwin binaries, I followed the historical procedure
of: build --without-postgres, then enable it and build the PostgreSQL
driver. The reason for this was so that NVIZ doesn't require libpq to
run.

However, it appears that NVIZ has long since stopped using libpq
(runPg.c is there, but it doesn't get compiled or linked). AFAICT, if
you build --with-postgres, the only program which will end up with a
dependency upon libpq is the PG driver (driver/db/pg).

OTOH, I could have sworn that someone was having problems quite
recently due to something (other than the PG driver) needing libpq.

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

11

Brad Douglas wrote:

The issue is dependencies. We already have a large number of
dependencies (as you have noticed). Requiring another very large
dependency is an issue, nor do I have the resources to create 5
different versions to accommodate each and every user (someone may want
Jasper, or Kakadu, or ECW...Sadly, we can't be all things to all people
with the current architecture). Also, keep in mind that most of us are
not compensated for our work. We are all volunteers here.

1 for and 1 against. Others?

Let's open this up to i386, too, since I also build RPMs for that
architecture as well.

One issue (which ties in with William Kyngesburye's recent bug report
on the issue) is that using including the results of
"gdal-config --dep-libs" in the linking switches will hard-code those
dependencies (and there may be a *lot* of them) into anything which
uses GDAL. Without those switches, you only need the dependencies for
the GDAL library which you are actually using, not the one with which
GRASS was compiled.

We should probably modify configure.in to check whether GDAL works
with just --libs, and only try with --dep-libs if that fails.

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

12

On 2/12/07, Craig Aumann <caumann@penguinmail.com> wrote:

I'm installing grass 62 on a Fedora 6, X86_64 machine. Originally, I
just pulled off the i386 rpms and installed those, but discovered that
they were NOT compiled with postgresql support for some reason. While I
don't mind compiling grass62 again with this support, the problem is
that the installed support libraries (gdal, proj, etc) are only for
i386... This is leading to all sorts of problems. How to find these
libraries for x86_64, etc...

Try Debian on Amd64, just type

# aptitude install grass

--
Damián D. Fossi Salas
¡Software Libre hasta el 2 mil siempre!

Uso:
Debian Etch > Kernel 2.6.18-3-686
Ubuntu Feisty Fawn > Kernel 2.6.19-amd64
Slackware 11 > Kernel 2.6.20-686
Ulanix 0.4-14 > Kernel 2.6.18-486
FreeBSD 6.2

Linux User: 188464
GPG Key Fingerprint = EC09 9ABA DFD8 83F0 36F3 CA89 356E 27FD E666 E6A4
Jabber ID: damianfossi en jabberes.org
www.damianfossi.com

13

On Thu, February 15, 2007 00:42, Glynn Clements wrote:

Brad Douglas wrote:

> We had enough problems building GRASS on FC6 that Markus had to help
us by
> directly logging into the machine. It turned out to be a very minor
issue,
> but infuriatingly difficult to find. Probably a growing number of
people are
> in the process of upgrading to FC6 so I'd like to add my vote for a
binary
> when you have time.

Okay. I'll try to throw something together for the 6.3 preview. There
won't be PostgreSQL support unless I can find a way to make it
completely modular.

AFAICT, that shouldn't be an issue any more.

When I made the Cygwin binaries, I followed the historical procedure
of: build --without-postgres, then enable it and build the PostgreSQL
driver. The reason for this was so that NVIZ doesn't require libpq to
run.

However, it appears that NVIZ has long since stopped using libpq
(runPg.c is there, but it doesn't get compiled or linked). AFAICT, if
you build --with-postgres, the only program which will end up with a
dependency upon libpq is the PG driver (driver/db/pg).

OTOH, I could have sworn that someone was having problems quite
recently due to something (other than the PG driver) needing libpq.

Maybe you are thinking of Huidae's WinGrass ? This was in September
(http://grass.itc.it/pipermail/grassuser/2006-September/036381.html), so I
don't know if this falls under "recently" ? :wink:

But so just to maje sure I understand: I can now build WinGrass directly
with Postgres support ? We have to test the other db drivers to see
whether the problems we are having are linked to the dbf driver or to the
general db framework.

Moritz

14

Moritz Lennert wrote:

> OTOH, I could have sworn that someone was having problems quite
> recently due to something (other than the PG driver) needing libpq.

Maybe you are thinking of Huidae's WinGrass ? This was in September
(http://grass.itc.it/pipermail/grassuser/2006-September/036381.html), so I
don't know if this falls under "recently" ? :wink:

That might have been what I remembered.

But so just to maje sure I understand: I can now build WinGrass directly
with Postgres support ?

Yes.

AFAICT, the only things which shouldn't be enabled are FFMPEG,
readline, BLAS, and LAPACK, as those will add additional dependencies
to modules which work fine without them.

[Technically, the same is true for PNG; the PNG driver (and direct
rendering) will work without it, but only produce PPM output (gis.m
only requires PPM output). If you wanted to be *really* careful about
dependencies, you could build two versions of libpngdriver, with and
without PNG support.]

FFMPEG is a "heavy" dependency (like GDAL), which can have a lot of
dependencies of its own, all of which then become essential
prerequisites in order to use NVIZ. The BLAS and LAPACK dependencies
don't actually get you anything unless you are writing new code using
a handful of (currently unused) libgmath functions. Readline is
relatively painless, but if it *does* break, it breaks r.mapcalc which
in turn breaks a lot of scripts.

All of the other --with-* switches result in additional modules being
built. Obviously, those modules won't work if their dependencies are
absent or non-functioning, but there's no harm in including a module
which may not work rather than simply not including it.

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