[bug #2180] (grass) Re: [GRASS5] C and C++ compiler changes?

GRASS GRASS developer
1

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

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

--- Headers Follow ---

From tlaronde@polynum.com Wed Oct 22 15:59:13 2003

Return-Path: <tlaronde@polynum.com>
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
  by lists.intevation.de (Postfix) with ESMTP id EF8531398D
  for <grass-bugs@lists.intevation.de>; Wed, 22 Oct 2003 15:59:12 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
  by mail.intevation.de (Postfix) with ESMTP id 003B536DD1
  for <grass-bugs@lists.intevation.de>; Wed, 22 Oct 2003 15:59:12 +0200 (CEST)
Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62])
  by mail.intevation.de (Postfix) with ESMTP id B5D3236DD0
  for <grass-bugs@intevation.de>; Wed, 22 Oct 2003 15:59:09 +0200 (CEST)
Received: from galois.polynum.com (lns-th2-13-82-64-77-40.adsl.proxad.net [82.64.77.40])
  by postfix4-1.free.fr (Postfix) with ESMTP
  id DEE5A64AF0; Wed, 22 Oct 2003 15:49:50 +0200 (CEST)
Received: (from tlaronde@localhost)
  by galois.polynum.com (8.9.3/8.9.3/Debian 8.9.3-21) id PAA10062;
  Wed, 22 Oct 2003 15:44:49 +0200
Date: Wed, 22 Oct 2003 15:44:49 +0200
From: Thierry Laronde <tlaronde@polynum.com>
To: Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject: Re: [GRASS5] C and C++ compiler changes?
Message-ID: <20031022154449.A10030@polynum.org>
References: <20031020211825.78C6F13B9A@lists.intevation.de> <20031021151649.A8008@polynum.org> <3F956B71.8070800@bowdoin.edu> <20031021200532.A9158@polynum.org> <20031022083600.GD28324@intevation.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20031022083600.GD28324@intevation.de>; from bernhard@intevation.de on Wed, Oct 22, 2003 at 10:36:00AM +0200
X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00
X-Spam-Level:

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

2

Request Tracker wrote:

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!).

Actual compiler bugs aren't necessarily the only issue. GCC's
optimisation has been getting increasingly aggressive over time.
Consequently, whereas you used to be able to get away with ignoring
C's aliasing rules, doing so now will often result in broken code when
optimisation is enabled.

Given the age and general clunkiness of much of GRASS' code, the
probability that aliasing bugs exist is rather high. Unfortunately,
such bugs can be hard to track down.

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).

We seem to have a fairly good record on these issues. Most of the
extensions which used to be in the code weren't glibc-specific, but
have been removed anyhow. E.g. snprintf() and setenv() are
non-standard but common, but I think that these have both been
eliminated (actually, setenv() is used if it exists but putenv()
doesn't).

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.

While C++ is inherently much more problematic (for portability) than
C, it doesn't help that the r.terraflow authors don't appear to have
given a particularly high priority to portability. Some of the issues
(e.g. the gcc-isms in the Gmakefile) are simply down to "works on my
system" syndrome.

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.

Agreed. Ideally I would like to be able to isolate the Unix-isms so
that GRASS could run natively on Windows (i.e. without requiring
Cygwin). There aren't actually that many issues; most of GRASS is
plain ANSI C. Probably the biggest single issue is the use of
system(), some of which is totally gratuitous, e.g. the use
system("rm ...") and system("mkdir ...").

BTW, there is a script (tools/sql.sh) which uses "nm" and "ldd" to
obtain symbol and library dependencies and feed them to an SQL
database. This can be used to identify which GRASS libraries and
modules require non-ANSI functionality.

Incidentally, this sort of thing was the main reason that I added
support for building shared libraries; i.e. so that "nm" and "ldd"
would distinguish between the dependencies between modules and GRASS
libraries and those between GRASS libraries and system libraries.

There are a few cases where it has demonstrated dubious dependencies.
E.g. the functionality in unix_socks.c results in libgis depending
upon the socket functionality (which is built into glibc, but may be
in e.g. libsocket on other Unices), although it is only actually used
by the raster and driver libraries.

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

3

On Wed, Oct 22, 2003 at 03:59:14PM +0200, Request Tracker wrote:

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

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!).

Naive question:
Should/can add we a test in the (G)makefile and disable certain gcc versions
to avoid too many "bug" reports?

Markus

4

Just a hint,
please only answer to the grass bugtracker address
if you want it to become part of the bug or a new bug report.

Unfortunatley parts of this conversation has gone to the bugtracker
and because we've canceled the entries, we do get new ones created
when you simply reply without removing the grass-bugs@ address.

On Thu, Oct 23, 2003 at 11:21:15AM +0200, Markus Neteler wrote:

On Wed, Oct 22, 2003 at 03:59:14PM +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2180

5

On Thu, Oct 23, 2003 at 11:21:15AM +0200, Markus Neteler wrote:

Naive question:
Should/can add we a test in the (G)makefile and disable certain gcc versions
to avoid too many "bug" reports?

YMMV. I'm not a compiler guru but I know (by reports and by experiences)
that there are in some cases problems with the new line of gcc. Since
we will be rapidly out of sync with new versions I only suggest to add
in the INSTALL file something like:

Obviously, to compile this package you need an ANSI/ISO C compiler
(with C++ support too). In case you hit some _runtimes_ problem (unusual
core dumps or even crashes) please verify that you are not using a
version of the compiler that is on the experimental leading edge.
For example, for gcc users, at the moment of the redaction,
gcc 2.95.3 is the most stable version.

If you run a more recent version (3.[0-3]) AND you have some strange
runtime problems, you can try to recompile first without any
optimization and perhaps downgrading too your machine's target
(compiling for a i486 when you have a i586 for example), or try a
compilation with gcc-2.95.3. But do it only when a problem occurs, just
in order to help us to identify the origine of the problem

Something like that.

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

6

Markus Neteler wrote:

Naive question:
Should/can add we a test in the (G)makefile and disable certain gcc versions
to avoid too many "bug" reports?

No.

If there are bugs in the version of gcc which ships with a particular
Linux distribution, the vendor will eventually provide an upgrade
which fixes the bug. The fixed version will probably be
indistinguishable from the broken version.

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