(attachments)
config.log (17.9 KB)
Compiling grass5.0.0 (19.3 KB)
config.log (17.9 KB)
Compiling grass5.0.0 (19.3 KB)
Sjors wrote:
I'm wondering if anybody tried compilng grass5.0.0 under redhat8.0. I seem
to get a lot of errors.
What errors, exactly?
Is the problem gcc3 and should I revert to gcc 2.98?
There are a few problems with gcc 3, primarily related to the fact
that it seems to default to C99. The result is that files which define
a function called round() fail to compile. However, most of GRASS5
should still compile.
I've attached the config.log, don't mind the failure with postgres. The
header is somehow not installed. <br>
config.log is only relevant to configure failures, not build failures.
Another question: are the grid3d modules still in experimental head and can
they be compiled with normal grass5.0.0 source?? <br>
The G3D code is currently being developed; fixes have been committed
in the last couple of days. The code should compile OK, but further
changes are likely.
--
Glynn Clements <glynn.clements@virgin.net>
Hi Glynn,
I'm sorry, my question of yesterday seemed premature. I've compiled grass5.0.0 now with postgres and ODBC on Redhat8.0 with gcc3.2 and it's working. Did not test all the modules, but the most seem to work.
I've also downloaded the eperimental HEAD source. Is it possible to just extract the grid3d modules, compile them and then insert them into normal grass code?? Or should I just remove the normal code and compile the HEAD version?? I trust that HEAD code is stable enough for normal modules and work, or is it still very buggy?
Another question is to do with the binaries. If I'm correct it's not possible to build a rpm with postgres and ODBC. At least with installing the binaries, they're never there. This is because I want to try and build rpm's at least for my own system (in general later) so installing grass5 won't take so much time. If it's to complex to anwser don't go through the trouble, I will experiment on my own and see. I will go on testing the normal code for now.
thanks and greetings
Sjors
Glynn Clements wrote:
Sjors wrote:
I'm wondering if anybody tried compilng grass5.0.0 under redhat8.0. I seem
to get a lot of errors.
What errors, exactly?
Sjors wrote:
I'm sorry, my question of yesterday seemed premature. I've compiled
grass5.0.0 now with postgres and ODBC on Redhat8.0 with gcc3.2 and it's
working. Did not test all the modules, but the most seem to work.
I've also downloaded the eperimental HEAD source. Is it possible to just
extract the grid3d modules, compile them and then insert them into
normal grass code?? Or should I just remove the normal code and compile
the HEAD version?? I trust that HEAD code is stable enough for normal
modules and work, or is it still very buggy?
It should be possible to add the grid3d modules to an existing
installation.
HEAD should be usable. If anything, it should have fewer bugs than the
5.0.0 release, as a number of bugs have been fixed since then.
The really experimental version (grass51) is a separate CVS module.
Another question is to do with the binaries. If I'm correct it's not
possible to build a rpm with postgres and ODBC. At least with installing
the binaries, they're never there. This is because I want to try and
build rpm's at least for my own system (in general later) so installing
grass5 won't take so much time. If it's to complex to anwser don't go
through the trouble, I will experiment on my own and see. I will go on
testing the normal code for now.
Neither PostgreSQL nor ODBC should cause any problems for building an
RPM. The binary packages from the GRASS website normally include the
PostgreSQL modules; however, the normal procedure is to build NVIZ
without PostgreSQL support, so that it will still work on a system
without PostgreSQL installed.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Sjors wrote:
I'm wondering if anybody tried compilng grass5.0.0 under redhat8.0. I seem
to get a lot of errors.
What errors, exactly?Is the problem gcc3 and should I revert to gcc 2.98?
There are a few problems with gcc 3, primarily related to the fact
that it seems to default to C99. The result is that files which define
a function called round() fail to compile. However, most of GRASS5
should still compile...
...yes it is (on grass5.0.0pre4). I tried with gcc3.2 and I had 'only' these compile errors:
GRASS GIS compilation log
-------------------------
Start of compilation: Fri Jan 17 11:05:50 CET 2003
Errors:
Compilation error in module: src/imagery/i.class (ignored)
Compilation error in module: src/imagery/i.ortho.photo (ignored)
Compilation error in module: src/imagery/i.points (ignored)
Compilation error in module: src/imagery/i.vpoints (ignored)
End of compilation: Fri Jan 17 11:19:29 CET 2003
DONE generating GRASS GIS binary code
If I remember I had these, also with gcc2.96.
Piero Cavalieri wrote:
> > Is the problem gcc3 and should I revert to gcc 2.98?
>
> There are a few problems with gcc 3, primarily related to the fact
> that it seems to default to C99. The result is that files which define
> a function called round() fail to compile. However, most of GRASS5
> should still compile......yes it is (on grass5.0.0pre4). I tried with gcc3.2 and I had
'only' these compile errors:GRASS GIS compilation log
-------------------------
Start of compilation: Fri Jan 17 11:05:50 CET 2003
Errors:
Compilation error in module: src/imagery/i.class (ignored)
Compilation error in module: src/imagery/i.ortho.photo (ignored)
Compilation error in module: src/imagery/i.points (ignored)
Compilation error in module: src/imagery/i.vpoints (ignored)
End of compilation: Fri Jan 17 11:19:29 CET 2003
DONE generating GRASS GIS binary codeIf I remember I had these, also with gcc2.96.
These aren't the problems to which I was referring; the round() errors
were in:
src/display/d.zoom/cmd/set.c
src/imagery/i.pca/cmd/main.c
I don't recall any specific problems with the above modules; I would
need to see the actual error messages to determine what was wrong. But
then a lot changed between -pre4 and the 5.0.0 release.
--
Glynn Clements <glynn.clements@virgin.net>