Re: GNAT 3.01 Source For OS/2

[dewar@cs.nyu.edu (Robert Dewar)]

Jerry said

"   It's not my job to go out and find bugs for YOU.  Ada Core Technology
simply screwed up 3.03.  Your 3.03 source on cs.nyu.edu WILL NOT WORK.
If you want me to go as far as specifing the exact lines of code that
are wrong I can do that !!!!  Do you REALLY want me to PROVE to the
open public that your 3.03 release is broken and CANNOT work ????

   When I do that, the clear implication will be that ACT is NOT providing
the Configuration Management and Version Control that one would expect from
ANY Ada developer.  I will be proving that the 3.03 source and executable on
cs.nyu.edu DO NOT match."

"specifying the exact lines of code" that you think are wrong would of
course be helpful. Can you please send a copy of this to report@gnat.com,
where it is most helpful since then it is sure to get to the right person.

As for your claim that the 3.03 source and executables do not match. This
is quite wrong. I have no idea what leads you to this incorrect conclusion,
but all 3.03 versions are built EXACTLY from the 3.03 sources as 
distributed, and all compile their own libraries.

If you are having trouble duplicating this build, most likely you are
just not doing the build the same way we are. For instance, our stndard
options for compiling the compiler are -gnatap (assertions on, range
checking off). We turn range checking off because it is our experience
that with assertions on, the range checking does not find additional
real errors, but has been known to cause problems (as appears to be
the case in your build). Of course the case you found should be fixed,
but as you have undoubtedly found out, the issue here is one of choosing
right subtypes, not a functoinality issue, i.e. the 3.03 compiler behaves
fine as we build it in this respect. It is possible that some of your
other problems with the build come from similar cases, or not. Hard
to say without more details.

The OS/2 compiler does get completely built at least once a day. The
problem in getting releases out is packaging and testing. In the future,
we are going to release the OS/2 directly from my working version, which
should make it easier to get OS/2 releases out. Before we were rebuilding
a referene version on another machine for the release, and this is teh
step that was taking time, and not getting done due to its low priority.
The disadvantage of this approach is that we are less likely to track
changes in EMX, since there is no point for me to update EMX versions
if my development version is working fine. Of course if some volunteer
can help with putting things together with the latest EMX, we would
be more than happy to work with them.