FreeBSD-8.2 and GNAT AUX – initial impressions

Over the past months I’ve written a few posts about the dragonlace.net project, which aims to bring the GNAT Ada compiler to the *BSD world and Solaris world.

They call their compiler GNAT AUX.

It is, as I’ve stated in previous posts, an impressive feat that GNAT AUX is now available for more or less all their targets.

So I decided to stop just reporting on the progress of GNAT AUX, and instead try it out myself. I’m more or less a complete BSD beginner, so the ride was somewhat bumpy due to me fumbling around. I chose FreeBSD-8.2 as my testing ground, and while it felt a lot like my dear and beloved Slackware, it was also sufficiently different to allow for a few “DUH!” moments as I learned the ropes. The _excellent_ FreeBSD online manual was a great help. I wish all operating systems had such a nice and concise manual.

With FreeBSD-8.2 up and running I installed the GNAT AUX port, and it just worked. It compiled cleanly without a hitch, and when it was done I had a nice Ada compiler running:

GNATMAKE 4.6.0 20110107 (experimental) -=> GNAT AUX [FreeBSD64]

Awesome!

Next up I grabbed the AWS port, and that too worked out of the box.

I even tried compiling AWS using the latest Git checkout

git clone --recursive http://forge.open-do.org/anonscm/git/aws/aws.git

And that too worked, almost, out of the box. I merely had to use “gmake” instead of “make”.

Two down, three to go.

I’m a big fan of GNATColl, so naturally I had to try and compile that also. There’s currently no port of GNATColl, so I had to do that manually. I grabbed the latest SVN checkout

svn co http://svn.eu.adacore.com/anonsvn/Dev/trunk/gps/gnatlib/

And compiled it according to instructions, except I needed to substitute “make” with “gmake”, just as with AWS.

I had a bit of trouble getting GNATColl to find my PostgreSQL installation, but that turned out to be because I’d installed the wrong PostgreSQL port. As soon as I installed the right one (postgresql-libpqxx) it worked. GNATColl compiled without a hitch. How very nice!

Last on the block was Florist, the Ada binding to POSIX. This is available from libre.adacore.com, and this too compiled without a hitch.

Everything appeared to be working just fine.

But then I tried the hello_world demo program that comes with AWS, and that did not go well. It compiled just fine, but when I tried to start it, it complained about a missing aws.ini file. I created that file, and then it complained about a missing hello_world.ini file. I also created that and silently hoped that the third try would be a success. Sadly it was not:

raised GNAT.SOCKETS.SOCKET_ERROR : [36] Operation now in progress

At that point I decided to give up on hello_world and instead try building my own AWS based web toolbox. It’s just a simple little project I’m working on, as a part of the ongoing effort of getting rid of PHP in my shop.

I grabbed the software and tried compiling it using plain gnatmake:

yolk-process_control.ads:99:63: "SIGPWR" not declared in "Names"

Hmm, not a good sign. I got rid of the offending “SIGPWR” handler and tried again, and now it compiled without issue. YAY!

I then tried running the demo application and got this:

Execution terminated by abort of environment task

I suspect maybe this has something to do with the fact that I setup my own signal handlers in the application, using the Ada.Interrupts.Names package.

Or maybe it’s because I use Florist/POSIX to switch user when the application start.

I don’t know, and I haven’t had time to investigate further.

So what have I learned from this experience:

  1. GNAT AUX is easy to install, and so is the rest of the dragonlace.net Ada port packages.
  2. AWS, GNATColl, Florist and my own toolbox compiles fine using GNAT AUX.
  3. The AWS hello_world demo and my own AWS application won’t run out of the box.

I’m very impressed with how easy it has been to get my usual Ada environment up and running on FreeBSD-8.2, and I’m not at all convinced that the errors I’m getting when trying to run the AWS hello_world and my own AWS application is not due to my own fault. I will have to investigate further, when time permits.

Leave a Reply