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-Thread: 103376,998480123ade4649 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.35.68 with SMTP id f4mr612878pbj.5.1321913868061; Mon, 21 Nov 2011 14:17:48 -0800 (PST) Path: lh20ni2985pbb.0!nntp.google.com!news1.google.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: will ada always be supported by gcc? Date: Mon, 21 Nov 2011 22:17:46 +0000 Organization: A noiseless patient Spider Message-ID: References: <87y5v9tasq.fsf@ludovic-brenta.org> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="12843"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19r8rS+KEOHXwcCa/1mSTpP7YkuIINRKe8=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin) Cancel-Lock: sha1:v8TOZ1sRYPBzOKQ5/+LUUqXEJzY= sha1:g8UQGj4/5srGTzTlhd0OvrNPdZg= Xref: news1.google.com comp.lang.ada:19011 Content-Type: text/plain; charset=us-ascii Date: 2011-11-21T22:17:46+00:00 List-Id: Ludovic Brenta writes: > But I think your question really was: "can I be sure that Ada will > continue to be part of the GCC compiler suite *on MacOS X* for a long > time?" I cannot answer that definitively; for starters, Apple's GCC > does not support Ada at all; the existing GNAT for MacOS X is pretty > much a community project, AFAICT, and so is no better and no worse > than GPC on Mac OS X. ??? Darwin is a standard build option in GCC; you can buy support for a Darwin GNAT from AdaCore or you can download the GPL version. The GCC maintainers don't regard Darwin as a primary target (unlike Linux). But it hasn't been a stopper so far. At the moment I think the difficulties arise with Apple oddities and even bugs: for example, PR42554[1] is down to Apple's introduction and then deprecation of "ranlib -c". PR50678[2] is caused by Apple's stack unwinding having a mistaken view of how registers are stored after a stack overflow, which only seems to affect GNAT. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554 [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678