[GRASS5] C and C++ compiler changes?

[Thierry Laronde]

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 at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C