[GRASS5] [bug #2173] (grass) Compiling under Mandrake 9.1

GRASS GRASS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=2173
-------------------------------------------------------------------------

Subject: Compiling under Mandrake 9.1

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.0.3rc4

To compile the source, had to change Line #48 in minmaxheap.h from #include <strstream.h> to #include <strstream>.

-------------------------------------------- Managed by Request Tracker

2

On Mon, Oct 20, 2003 at 11:18:25PM +0200, Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=2173
-------------------------------------------------------------------------

Subject: Compiling under Mandrake 9.1

To compile the source, had to change Line #48 in minmaxheap.h from #include <strstream.h> to #include <strstream>.

These are the preliminary problems with all the C++ code and the new
GCC 3.x...
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

3

Hi,

As far as I can tell all the compile problems with r.terraflow are because of the #include lines.
With gcc3.2 and 3.3 all #include <X.h> should be replaced with #include <X>.
Also, the header strstream.h is deprecated, and should be replaced with sstream.

With 3.2 these problems can be postponed with the compile flag -Wno-deprecated. Not sure about 3.3. I will try to install 3.3 and compile it.

In any case the code should be fixed to compile without warnings (and errors).. I'll be working on it.

-Laura

Thierry Laronde wrote:

On Mon, Oct 20, 2003 at 11:18:25PM +0200, Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=2173
-------------------------------------------------------------------------

Subject: Compiling under Mandrake 9.1

To compile the source, had to change Line #48 in minmaxheap.h from #include <strstream.h> to #include <strstream>.
   
These are the preliminary problems with all the C++ code and the new
GCC 3.x...

4

Hello,

On Tue, Oct 21, 2003 at 01:22:57PM -0400, Laura Toma wrote:

Hi,

As far as I can tell all the compile problems with r.terraflow are
because of the #include lines.
With gcc3.2 and 3.3 all #include <X.h> should be replaced with #include
<X>.
Also, the header strstream.h is deprecated, and should be replaced with
sstream.

With 3.2 these problems can be postponed with the compile flag
-Wno-deprecated. Not sure about 3.3. I will try to install 3.3 and
compile it.

In any case the code should be fixed to compile without warnings (and
errors).. I'll be working on it.

Great. All I wanted to emphasize ---since I have spent some times trying
to convince GNU libc (latest) and GNU cc (latest) to compile smoothly
together...--- is that we are going to have some hard time with mixes
of different versions of gcc and glibc... And the C++ support has deeply
changed too!

Cheers,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

5

On Tue, Oct 21, 2003 at 08:05:32PM +0200, Thierry Laronde wrote:

On Tue, Oct 21, 2003 at 01:22:57PM -0400, Laura Toma wrote:
> As far as I can tell all the compile problems with r.terraflow are
> because of the #include lines.
> With gcc3.2 and 3.3 all #include <X.h> should be replaced with #include
> <X>.
> Also, the header strstream.h is deprecated, and should be replaced with
> sstream.

I'll take it this exclusively holds for C++?
It would be interesting to get a pointer to the rationale behind it.

Anyway this is a point where I'm glad that the tradition
is to keep a lot of GRASS' code in plain C.

> In any case the code should be fixed to compile without warnings (and
> errors).. I'll be working on it.

Great. All I wanted to emphasize ---since I have spent some times trying
to convince GNU libc (latest) and GNU cc (latest) to compile smoothly
together...--- is that we are going to have some hard time with mixes
of different versions of gcc and glibc... And the C++ support has deeply
changed too!

Well it is _only_ about the C++ support as far as I always understood this.
Mixing most of the plain C libraries have never been a major problem.
Am I missing something?

6

Bernhard Reiter wrote:

> > As far as I can tell all the compile problems with r.terraflow are
> > because of the #include lines.
> > With gcc3.2 and 3.3 all #include <X.h> should be replaced with #include
> > <X>.
> > Also, the header strstream.h is deprecated, and should be replaced with
> > sstream.

I'll take it this exclusively holds for C++?

Yes.

--
Glynn Clements <glynn.clements@virgin.net>

7

On Wed, Oct 22, 2003 at 10:36:00AM +0200, Bernhard Reiter wrote:

On Tue, Oct 21, 2003 at 08:05:32PM +0200, Thierry Laronde wrote:
>
> Great. All I wanted to emphasize ---since I have spent some times trying
> to convince GNU libc (latest) and GNU cc (latest) to compile smoothly
> together...--- is that we are going to have some hard time with mixes
> of different versions of gcc and glibc... And the C++ support has deeply
> changed too!

Well it is _only_ about the C++ support as far as I always understood this.
Mixing most of the plain C libraries have never been a major problem.
Am I missing something?

No, in the sense that the "user apparent" changes are with the C++ part.
But unfortunately, GCC 3.3.1 for example has some bugs in optimization
and inlining meaning that we will have some rough times with compilation
failures reports that may be caused by bugs in the compiler and not in
the code (for example some version(s) of glibc doesn't compile with it
and one can compile a Linux kernel with it that will cause bugs (in my
case this was reboot) : but compilation succeeds...; so imagine the
hell if a glibc compiles but is buggy!).

As for the GNU libc, this is also a problem at the moment because glibc
is not only libc, it's a bundle of libraries and extensions and,
unfortunately, people use to develop with glibc forgetting that some
features are GNU idiosynchrasies and thinking that there are "standard"
and compilation may fell with other libraries, or even fail compiling
against another version of glibc since these extensions change from
time to time (I have experienced this too this week-end).

Synthesis: there may be in the future reports about C++ (need to be
fixed because the 3.x series of GCC has changed a lot of things in
this area) and reports about compiling failures that are caused by
particular mixes between versions of GCC and glibc but not because
GRASS code is in itself buggy.

I agree with you that we must stick as much as possible to C, and I
add strict ANSI/ISO C and strict POSIX functions, clearly making the
distinctions between what is standard and what is not: we need in this
case to provide the libraries or to set a dependency against one open
implementation.

--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

8

Bernhard Reiter wrote:

On Tue, Oct 21, 2003 at 08:05:32PM +0200, Thierry Laronde wrote:

On Tue, Oct 21, 2003 at 01:22:57PM -0400, Laura Toma wrote:
   

As far as I can tell all the compile problems with r.terraflow are because of the #include lines.
With gcc3.2 and 3.3 all #include <X.h> should be replaced with #include <X>.
Also, the header strstream.h is deprecated, and should be replaced with sstream.
     
I'll take it this exclusively holds for C++?
It would be interesting to get a pointer to the rationale behind it.

Anyway this is a point where I'm glad that the tradition
is to keep a lot of GRASS' code in plain C.

Yes, only for C++. It certainly is a pain to maintain C++ with the new gcc 3.x, but there's no way around it..It's the price to pay for efficient code.

The main reason r.terraflow is in C++ instead of C is templating. All functions are templated and the type is determined at runtime, causing the appropriate function to be instantiated. This is more efficient than using void* in C, and also saves *a lot* of redundant code.

In any case the code should be fixed to compile without warnings (and errors).. I'll be working on it.
     

Great. All I wanted to emphasize ---since I have spent some times trying
to convince GNU libc (latest) and GNU cc (latest) to compile smoothly
together...--- is that we are going to have some hard time with mixes
of different versions of gcc and glibc... And the C++ support has deeply
changed too!
   
Well it is _only_ about the C++ support as far as I always understood this.
Mixing most of the plain C libraries have never been a major problem.
Am I missing something?

yes, only for C++.

-Laura

9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thierry Laronde wrote:

On Wed, Oct 22, 2003 at 10:36:00AM +0200, Bernhard Reiter wrote:

On Tue, Oct 21, 2003 at 08:05:32PM +0200, Thierry Laronde wrote:

Great. All I wanted to emphasize ---since I have spent some times trying
to convince GNU libc (latest) and GNU cc (latest) to compile smoothly
together...--- is that we are going to have some hard time with mixes
of different versions of gcc and glibc... And the C++ support has deeply
changed too!

Well it is _only_ about the C++ support as far as I always understood

this.

Mixing most of the plain C libraries have never been a major problem.
Am I missing something?

No, in the sense that the "user apparent" changes are with the C++ part.
But unfortunately, GCC 3.3.1 for example has some bugs in optimization
and inlining meaning that we will have some rough times with compilation
failures reports that may be caused by bugs in the compiler and not in
the code (for example some version(s) of glibc doesn't compile with it
and one can compile a Linux kernel with it that will cause bugs (in my
case this was reboot) : but compilation succeeds...; so imagine the
hell if a glibc compiles but is buggy!).

The whole of Mandrake Linux is compiled with gcc-3.3.1 (probably with
quite a few patches from cvs), and there haven't been any bugs found
recently (2 months or so) that were traced to gcc.

My cvs builds of grass51 work fine on Mandrake 9.2/cooker, after fixing
the use of the deprecated headers.

Regards,
Buchan

- --
|--------------Another happy Mandrake Club member--------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/lqsBrJK6UGDSBKcRAos+AKCvwOtkDNxneB5ldPegFjPzstxH7wCeJVq8
iPdzxsUiFxFZ86WBQyIxbKM=
=nUK0
-----END PGP SIGNATURE-----

10

On Wed, Oct 22, 2003 at 06:06:25PM +0200, Buchan Milne wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thierry Laronde wrote:
> But unfortunately, GCC 3.3.1 for example has some bugs in optimization
> and inlining meaning that we will have some rough times with compilation
> failures reports that may be caused by bugs in the compiler and not in
> the code (for example some version(s) of glibc doesn't compile with it
> and one can compile a Linux kernel with it that will cause bugs (in my
> case this was reboot) : but compilation succeeds...; so imagine the
> hell if a glibc compiles but is buggy!).

The whole of Mandrake Linux is compiled with gcc-3.3.1 (probably with
quite a few patches from cvs), and there haven't been any bugs found
recently (2 months or so) that were traced to gcc.

Perhaps, but one bird doesn't mean spring has came. Note that a recent
Mandrake is shipped with a gcc-3.3.1, _but_ 3.3.2 fixes important bugs.
And we don't know what version (with patches or not) of the libc
software have been compiled against (since gcc-3.3.1 INSTALL says don't
try to compile the new libc this will lead to problems, while glibc
INSTALL says get the latest version of gcc...).

Perhaps this very version shipped with Mandrake has the right fixes but
since a majority of the people who will compile their software are the
ones who will fearlessly try to compile glibc and gcc on their own
(perhaps simply because package foo says `I need glibc latest') they
will have new libc static and shared to link against and everything will
go live.

This is not a criticism against Mandrake or others, this is just a
caveats: we need to know with every report what are the compiler
(origine and version) and the libc (and by the way the locales too
since running anything other than `env LC_ALL=C LANGUAGE=C ./configure
[options]' is problematic too).

And perhaps should we recommend a particular version of the compiler
(and at least "our" build daemons need to run a fairly stable version
of an ANSI C (C++) compiler with a fairly stable libc so that we can
ship binaries for the ones unable to compile).

Cheers,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

11

Laura Toma wrote:

Yes, only for C++. It certainly is a pain to maintain C++ with the new
gcc 3.x, but there's no way around it..It's the price to pay for
efficient code.

The main reason r.terraflow is in C++ instead of C is templating.

In that case, some portability issues are probably inevitable.
Templates were one of the last things to be standardised, and one of
the last things to be fixed in gcc.

All
functions are templated and the type is determined at runtime,

Er, compile time, right? Or is it using virtual methods?

causing
the appropriate function to be instantiated. This is more efficient than
using void* in C, and also saves *a lot* of redundant code.

Is this just for ELEV_SHORT vs ELEV_FLOAT, or is it more extensive
than that?

--
Glynn Clements <glynn.clements@virgin.net>

12

On Wed, Oct 22, 2003 at 06:44:55PM +0200, Thierry Laronde wrote:

This is not a criticism against Mandrake or others, this is just a
caveats: we need to know with every report what are the compiler
(origine and version) and the libc (and by the way the locales too
since running anything other than `env LC_ALL=C LANGUAGE=C ./configure
[options]' is problematic too).

Yes if strange problems occur more information about the system
including versions of the C library and the compiler might
be necessary to find the actual bugs.
In many cases though, the first reality check is to see if
the same bug can be reproduced on other systems which
often is the case. So there is no immedeate need to make reporting
compiler and library versions in bug report mandatory.

And perhaps should we recommend a particular version of the compiler
(and at least "our" build daemons need to run a fairly stable version
of an ANSI C (C++) compiler with a fairly stable libc so that we can
ship binaries for the ones unable to compile).

I don't think we should recommend particular versions
of compilers and c libraries. It is interesting to get reports
from people that can compile and run a certain version of GRASS
on their platform.

I wrote my remark on the first two postings
because they could give the false impression that GNU compiler
and C libraries are somewhat unstable. Actually gcc and GNU libc
are very stable and reliable on the C part in the overall picture.
The original postings were not making clear that most statements
were geared towards the C++ situation, which indeed is not as
stable as everybody likes. I credit some of those difficulties
to the C++ language. :slight_smile:

13

On Thu, Oct 23, 2003 at 11:06:35AM +0200, Bernhard Reiter wrote:

I wrote my remark on the first two postings
because they could give the false impression that GNU compiler
and C libraries are somewhat unstable. Actually gcc and GNU libc
are very stable and reliable on the C part in the overall picture.
The original postings were not making clear that most statements
were geared towards the C++ situation, which indeed is not as
stable as everybody likes. I credit some of those difficulties
to the C++ language. :slight_smile:

Life is strange some days :wink: Here I can be thought as a GNU disliker
when today, at work, we have received a message from a software
compagny that has proposed a... GIS software, that I have tested (since
I'm the only one with some development knowledge) and refused, having
prefered, for _technical reasons_, GRASS, and in this message that was
sent to the only email address of our little structure and was meant to
be read only by my boss, they explain that _I_ have discarded their
software because I'm biased (I'm a well known Unix and libre software
fighter) and that my boss should not trust me since I'm not competent
and I'm (this is written white on black): an arsehole!!! (en français
dans le texte : "Ce mec est un trou de bal (sic).").

Unfortunately, I have done the job with GRASS, and the customer is
delighted (and to my surprise has appreciated that the work was done
with GRASS since "it's better to have software you have full control
over").
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

14

On Wednesday, October 22, 2003, at 09:07 PM, Glynn Clements wrote:

Laura Toma wrote:

Yes, only for C++. It certainly is a pain to maintain C++ with the new
gcc 3.x, but there's no way around it..It's the price to pay for
efficient code.

The main reason r.terraflow is in C++ instead of C is templating.

In that case, some portability issues are probably inevitable.
Templates were one of the last things to be standardised, and one of
the last things to be fixed in gcc.

yes..should not be a problem on any platform for which gcc is supported. but won't work with other compilers.

All
functions are templated and the type is determined at runtime,

Er, compile time, right? Or is it using virtual methods?

yes, i meant compile time. no virtual methods (they're slow).

causing
the appropriate function to be instantiated. This is more efficient than
using void* in C, and also saves *a lot* of redundant code.

Is this just for ELEV_SHORT vs ELEV_FLOAT, or is it more extensive
than that?

essentially that's it, plus all the type that include these two. practically everything is templated.

--
Glynn Clements <glynn.clements@virgin.net>

-Laura