From: (see below) on
On 23/12/2009 23:44, in article
eeaf5cb6-a582-4c90-a494-bd17142600a8(a)v25g2000yqk.googlegroups.com, "sjw"
<simon.j.wright(a)mac.com> wrote:

> On Dec 23, 5:18�pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote:
>> On 23/12/2009 14:26, in article
>> 68e6e09a-9f02-4fd4-a87c-d1c43dd10...(a)27g2000yqr.googlegroups.com, "sjw"
>> <simon.j.wri...(a)mac.com> wrote:
>>> On Dec 23, 3:29�am, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote:
> [...]
>>>> What on earth has happened for GNAT to regress so badly in the face of what
>>>> is often described as a tidying-up and performance release of OS X?
>>
>>> I don't know either, because here it compiles without complaint at -O
>>> {0,1,2,3}!
>>
>> Hmm. Interesting ...
>> What could account for the difference?
>> Do you have any other versions of GNAT installed in that testing
>> environment?
>
> Several! though I'd be surprised if any of them got invoked. Will
> check further.

What I had in mind was interference between libraries, etc.

--
Bill Findlay
<surname><forename> chez blueyonder.co.uk


From: sjw on
On Dec 24, 12:01 am, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote:
> On 23/12/2009 23:44, in article
> eeaf5cb6-a582-4c90-a494-bd1714260...(a)v25g2000yqk.googlegroups.com, "sjw"
> <simon.j.wri...(a)mac.com> wrote:
> > On Dec 23, 5:18 pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote:
> >> On 23/12/2009 14:26, in article
[...]
> >> Do you have any other versions of GNAT installed in that testing
> >> environment?
>
> > Several! though I'd be surprised if any of them got invoked. Will
> > check further.
>
> What I had in mind was interference between libraries, etc.

Each compiler I have installed lives in a different top-level
directory. I set my path using

$ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin

(ie, the 32-bit Snow Leopard compiler I just released on SF); now I
can compile your example without trouble. Did you use more options?

nidhoggr:findlay simon$ gnatmake -f test
gcc -c test.adb
nidhoggr:findlay simon$ gnatmake -f test -O0
gcc -c -O0 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O1
gcc -c -O1 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O2
gcc -c -O2 test.adb
nidhoggr:findlay simon$ gnatmake -f test -O3
gcc -c -O3 test.adb
nidhoggr:findlay
From: sjw on
On Dec 22, 5:10 pm, sjw <simon.j.wri...(a)mac.com> wrote:
> On Dec 22, 2:23 pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote:
>
> > On 22/12/2009 12:09, in article
> > af608388-8088-4779-a3ca-39275fd2c...(a)r24g2000yqd.googlegroups.com, "sjw"
>
> > <simon.j.wri...(a)mac.com> wrote:
> > > I've just released a 32-bit build of GNAT GPL 2009 for Snow Leopard;
> > > find it athttp://sourceforge.net/projects/gnuada/files/(navigateto
> > > GNAT_GPL Mac OS X/2009-snow-leopard-i386).
>
> > Many thanks -- I'll try it ASAP.
> > Any chance of a 64-bit build?
>
> Will have a go, but it's a cross-build so may take some getting my
> head round!

The cross-build (I think I may be wrong about that; perhaps there's an
'architecture' switch?) eventually produced a compiler. Unfortunately
it wouldn't process the simplest exception properly (SIGABRT).

I then had the idea, since the problem that stops building is that
init.c calls sigreturn() which isn't present in Snow Leopard, why not
fake up our own sigreturn() that does exactly what the patch did, then
link against that?

This turned out to work as hoped, result being that we can use Apple's
GNAT-GPL-2009 on Snow Leopard; see http://sourceforge.net/projects/gnuada/files/(navigate
to GNAT_GPL Mac OS X/2009-snow-leopard, get sigreturn.tar.bz2).

Sadly, the failure to handle exceptions with the 64-bit compiler is
unchanged (the 32-bit compiler is OK):

with Ada.Text_IO; use Ada.Text_IO;
procedure Raiser is
begin
begin
raise Constraint_Error;
exception
when Constraint_Error =>
Put_Line ("CE raised.");
end;
end Raiser;

nidhoggr:Test simon$ GNAT_PREFIX=/opt/gnat-gpl-2009_64-leopard
gnatmake -g -f raiser -largs sigreturn-64.o
gcc -c -g raiser.adb
gnatbind -x raiser.ali
gnatlink raiser.ali -g sigreturn-64.o
nidhoggr:Test simon$ ./raiser
Segmentation fault


Rats.
From: John B. Matthews on
In article
<f0b47208-95f0-48ef-8184-9f36f2a2f6bb(a)a32g2000yqm.googlegroups.com>,
sjw <simon.j.wright(a)mac.com> wrote:

> Each compiler I have installed lives in a different top-level
> directory. I set my path using
>
> $ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin

FWIW, here's a bash shell script I use to show the current PATH and the
alternative. The checkPath() and removePath() functions could be used in
managing multiple versions:

<http://home.roadrunner.com/~jbmatthews/gtk/lady.html#ada.sh>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: sjw on
On Dec 24, 3:31 pm, "John B. Matthews" <nos...(a)nospam.invalid> wrote:
> In article
> <f0b47208-95f0-48ef-8184-9f36f2a2f...(a)a32g2000yqm.googlegroups.com>,
>
>  sjw <simon.j.wri...(a)mac.com> wrote:
> > Each compiler I have installed lives in a different top-level
> > directory. I set my path using
>
> >   $ export PATH=/opt/gnat-gpl-2009/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> FWIW, here's a bash shell script I use to show the current PATH and the
> alternative. The checkPath() and removePath() functions could be used in
> managing multiple versions:
>
> <http://home.roadrunner.com/~jbmatthews/gtk/lady.html#ada.sh>

Thanks for that.

I was meaning to reply specifically to Bill's query about possible
clashes caused by multiple compiler installations.

For normal work, I use a script gnatfe - https://sourceforge.net/projects/gnuada/files/,
navigate to gnatfe.