Re: A bug in gnat/gcc 3.3.3?

[Ludovic Brenta <ludovic.brenta@insalien.org>]

Martin Krischik writes:
> Compiling ASIS and GLADE for a newer version isn't that difficult -
> even SuSE managed that for SuSE 9.2 - including x86_64
> architecture. On the down side SuSE only supplies 3.3.4 which is not
> that helpfull :-( .

If that is true, I am interested.  But my understanding is that both
are coupled with the internals of GNAT (with good reason, of course,
considering what they do).  Several people on this newsgroup have been
harping on GCC 3.4, but I'd like reports about ASIS and GLADE for GCC
3.4.

As a distribution maintainer, I also have configuration management
issues in mind.  Ada Core is not doing any formal releases of ASIS or
GLADE for GCC 3.4.  If I were to roll my own snapshot of the CVS
repositories and distribute them, I would be taking quite a big
responsibility both to the users (who tend to trust Debian packages),
and to Debian (which has a reputation for quality).  CVS snapshots
would be okay for the "experimental" branch of Debian, but not, IMHO,
for "stable".  I'm willing to be persuaded otherwise by people willing
to contribute some time and energy.

This also applies to Duncan's remark about the snapshot of GCC at the
"pre-ssa" tag, with one more twist: gnat-3.4 is part of the larger
gcc-3.4 source package (complete with 8 language front-ends, several
libraries, and accompanying docs).  Providing yet another
experimental, not binary-compatible, gnat is not particularly
appealing to me.  The quality level of "pre-ssa" is completely
orthogonal to this.

More generally, it seems to me that many people on this newsgroup like
to take their own snapshot of this, patch it, and then mix it with
their neibour's snapshot of that.  This is called chaos, and it works
because the software produced is often excellent.  But the resulting
source packages are bound to require different versions of GNAT, and
the only way to make them agree on one compiler is to use force
(i.e. patch until the damn things will compile, because the upstream
authors won't do it for you).  As a distribution maintainer and as one
who has compiled many free Ada packages, I am extremely sensitive to
this issue.

> Besides: GCC 3.4 has PolyORB which seems the better option anyway.

This statement is not true.  GCC 3.4 does not "have" PolyORB, they are
two separate packages.  To illustrate this, the Libre site also
mentions GNAT 3.16a1 and 5.02a along with GCC 3.4 as being compatible
with PolyORB.  Other versions are not necessarily incompatible; they
are just untested.

However, PolyORB is slated to replace GLADE in the future.  Parts of
it are being merged into GCC 4.0, so in the future you will be able to
say "PolyORB requires GCC 4.0 to build, and GCC 4.0 has special
support for PolyORB".

Is anyone aware of a binary distribution of PolyORB?

-- 
Ludovic Brenta.