From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5f7d72bde5bb96de X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-26 16:12:37 PST Path: archiver1.google.com!news1.google.com!news.glorb.com!tiscali!newsfeed1.ip.tiscali.net!news.worldonline.be!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Is 3.15p -still- the latest GNAT 'p' release? Date: 27 Mar 2004 01:15:14 +0100 Organization: Worldonline Belgium Sender: lbrenta@deuteronomy Message-ID: <878yhnywkt.fsf@insalien.org> References: <87wu5834r2.fsf@insalien.org> <40641888.80000@noplace.com> NNTP-Posting-Host: 83-134-237-107.lindthout.goplus.fastdsl.tiscali.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.worldonline.be 1080346350 5834 83.134.237.107 (27 Mar 2004 00:12:30 GMT) X-Complaints-To: abuse@worldonline.be NNTP-Posting-Date: Sat, 27 Mar 2004 00:12:30 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Xref: archiver1.google.com comp.lang.ada:6575 Date: 2004-03-27T01:15:14+01:00 List-Id: Mark H Johnson writes: > Marin David Condic wrote: > > You could probably freeze 3.15p and never make another release and > > still have a perfectly usable product. > > Actually on Linux, that is not quite true. I have a very large system > implemented on GNAT / Linux (still 3.14a, but compatible with 3.17w) > but someday, we have to step up beyond Red Hat 7.3 to something a > little more modern. At that point, we have the pthread compatibility > issue to deal with. We have the following options at that point: > > - step up to 3.16 or later to stay with the older backend > - step up to 5.02 or later to use the new backend > > Both of these official compiler releases have RH <9 and RH >=9 > versions available. > > I don't expect the first option to be a good long term strategy > because I expect ACT to drop support for the 3.xx compilers within a > year or so. They haven't said that directly but the following > statement in the 5.02a release notification appears to imply that... > "The 5.02a release completes the transition from GNAT3 to GNAT5 for > most of the GNAT Pro configurations." So, you seem to be a paying customer of ACT's. Good. This means that ACT does all the work of validating the compiler against several platforms for you. > The second option is also not quite as clean as we would like. The > backend in 5.xx appears to do more aggressive optimization and we have > some broken code to fix (it appears we need to add some more pragmas > for aliasing or volatile). It is an annoyance at this point (since we > obviously have working code / compiler) but time will be needed to > make the fixes. > > Yes - I am aware of the environment variable work around, but I don't > see that as a good long term strategy either. > --Mark >From what I understand, the problem, then, is neither Ada, nor ACT, nor GNAT, nor the pthreads library, but only the fact that "someday, [you] will have to step up beyond Red Hat 7.3 to something a little more modern". If you have strong validation requirements, you will have to explain why you absolutely have to move away from Red Hat 7.3 (as a side note, I still consider that particular release the best ever from Red Hat; the ones after that were, IME, of lesser quality). If you can justify the effort of re-validating your application on a newer Red Hat, then surely the effort of switching compilers will be minimal compared to it, given that ACT already does most of the work for you. If you are looking for a long-term strategy, then your first task is to define long-term. Then, try to find a platform, the long-term strategy of which matches yours as closely as possible. For example, Red Hat has 6-month release cycles; Red Hat Advanced Server has 3-year release cycles; and Debian has a "when it's ready" release cycle. Use Debian :) -- Ludovic Brenta.