From: (see below) on 23 Dec 2009 19:01 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 24 Dec 2009 09:50 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 24 Dec 2009 10:01 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 24 Dec 2009 10:31 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 24 Dec 2009 12:24
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. |