Re: [Plplot-devel] Need small change to the way Ada bindings are
built

On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote:
> On 2012-05-10 00:59-0700 Jerry wrote:
>
>>> Hi Jerry:
>>>
>>> I think the above change will screw up our installed Ada examples
>>> build which exclusively uses the gnatmake approach. So please test
>>> the installed examples build with and without the above change to see
>>> whether that hypothesis is correct.
>>>
>>> To remind you how to do such testing do your normal procedure
>>> for building and installing PLplot. Then
>>> run cmake in an empty directory
>>> with no options and with just a reference to the installed examples
>>> tree like this:
>>>
>>> # insures initially empty build tree.
>>> rm -rf test_install_build
>>> mkdir test_install_build
>>> cd test_install_build
>>>
>>> cmake /usr/local/plplot/share/plplot5.9.9/examples
>>>
>>> then
>>>
>>> make test_ada_psc
>>>
>>> That make command should work fine for an unmolested install, but if
>>
>> Hmm.... I did this
>>
>> cd /usr/local/dumpme
>> rm -rf test_install_build
>> mkdir test_install_build
>> cd test_install_build
>> cmake /usr/local/plplot/share/plplot5.9.9/examples
>> make test_ada_psc
>>
>>
>> and got this...
>>
>>
>> Generate ada results for psc device
>> Testing front-end ada
>> x01
>> /usr/local/plplot/share/plplot5.9.9/examples/test_ada.sh: line 32: 34044 Trace/BPT trap: 5 "$adadir"/x${index}${lang} -dev $device -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >|"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
>> dyld: Library not loaded: @rpath/libgnat-2010.dylib
>> Referenced from: /usr/local/dumpme/test_install_build/./ada/x01a
>> Reason: image not found
>> make[3]: *** [x01a.psc] Error 1
>> make[2]: *** [CMakeFiles/test_ada_psc.dir/all] Error 2
>> make[1]: *** [CMakeFiles/test_ada_psc.dir/rule] Error 2
>> make: *** [test_ada_psc] Error 2
>>
>>
>> I tried to supply the path to what I think it is asking for but I'm not sure how to do that.
>
> Hi Jerry:
>
> I am not familiar with the Mac OS X platform, but from the message above
> it looks to me like
> the run-time loader that executes x01a is having trouble locating
> libgnat-2010.dylib in your new installation.
I've puzzled over @rpath before--can't remember what I learned but I don't think it was much.
> Isn't there a standard
> environment variable you can set (LD_LIBRARY_PATH works for Linux) to
> help address such issues?
>
> I assume you would get the same error for the core build system as
> well, but to check that do a clean _core_ build of PLplot using
> the cmake option, -DBUILD_TEST=ON
I always do.
>
> then run
>
> make test_ada_psc
What do I cd to before running this?
BTW the results that I reported before were with the 2010 compiler but the 2011 compiler makes the exact same output but with
dyld: Library not loaded: @rpath/libgnat-2011.dylib
^
All for tonight (U.S. west)
Jerry
>
> as above. But this will be in the build tree of the core build rather
> than the build tree of the installed examples. Of course, if the
> core build version works while the above installed example version
> does not, then compare exact commands that are run in each case using
>
> make VERBOSE=1 test_ada_psc
>
> But I am virtually positive you will get the same result for core
> build and installed examples build since virtually the same CMake code
> is used in both cases.
>
> By the way, the test_ada_psc target runs the Ada subset of what is
> done for all language bindings and examples with the
> test_noninteractive target. And if I recall correctly you have run
> that test_noninteractive target in the past with no issues. Once this
> current "run time loader cannot find Ada system library" issue is
> addressed for your current Ada installation, I strongly encourage you
> to run the test_noninteractive target (or at least the Ada subset of
> that test with the target name "test_ada_psc") more often so that
> _every_ system and PLplot change is tested right after the change
> occurs (rather than days or months later when you have forgotten the
> details of the change).
>
> Alan

Thread view

I recently updated my Ada compiler from the 2010 GPL version provided by Adacore (the commercial source) to the 2011 version and encountered a rather odd problem when trying to link the Ada bindings into my own project.
GCC Ada aka GNAT and its tools provide two systems of building stuff--the older and still-used one uses the gnatmake and related commands, providing a somewhat traditional way of passing arguments on to the gcc tools.
The other system is called GPR (Gnat PRoject), gprbuild, and one writes some relatively sane-looking files that do the same thing as gnatmake et al and more. This is the system that I have used, in very simple ways.
I don't know if what I'll describe in a bit is necessary for gnatmake but is seems so for gprbuild. It is a complete mystery why this worked for the 2010 tools at all without the following change, which I believe we should incorporate into the PLplot build. It's really simple.
Copy
/usr/local/plplot/lib/libplplotadad.0.0.0.dylib
/usr/local/plplot/lib/libplplotadad.0.dylib
/usr/local/plplot/lib/libplplotadad.dylib
to
/usr/local/plplot/lib/ada/adalib/plplotadad
where /usr/local/plplot is my installation directory. That's it. When I do this manually, my personal stuff builds using the 2011 tools, but if I don't do it the 2011-tool build fails. There are some other files in the target directory, ending in .ali--these should remain--the .dylib needs to be in the same folder as these .ali. I suppose another directory would suffice as long as the .dylib and .alis are in it.
Jerry
P.S. I am fighting another issue with building PLplot that might be related to my recent update of OS X from 10.6.x to 10.7.x, but I think this is an orthogonal issue to the above and not Ada-related.

On 2012-05-09 01:36-0700 Jerry wrote:
> I recently updated my Ada compiler from the 2010 GPL version provided by Adacore (the commercial source) to the 2011 version and encountered a rather odd problem when trying to link the Ada bindings into my own project.
>
> GCC Ada aka GNAT and its tools provide two systems of building stuff--the older and still-used one uses the gnatmake and related commands, providing a somewhat traditional way of passing arguments on to the gcc tools.
>
> The other system is called GPR (Gnat PRoject), gprbuild, and one writes some relatively sane-looking files that do the same thing as gnatmake et al and more. This is the system that I have used, in very simple ways.
>
> I don't know if what I'll describe in a bit is necessary for gnatmake but is seems so for gprbuild. It is a complete mystery why this worked for the 2010 tools at all without the following change, which I believe we should incorporate into the PLplot build. It's really simple.
>
> Copy
>
> /usr/local/plplot/lib/libplplotadad.0.0.0.dylib
> /usr/local/plplot/lib/libplplotadad.0.dylib
> /usr/local/plplot/lib/libplplotadad.dylib
>
> to
>
> /usr/local/plplot/lib/ada/adalib/plplotadad
>
> where /usr/local/plplot is my installation directory. That's it. When I do this manually, my personal stuff builds using the 2011 tools, but if I don't do it the 2011-tool build fails. There are some other files in the target directory, ending in .ali--these should remain--the .dylib needs to be in the same folder as these .ali. I suppose another directory would suffice as long as the .dylib and .alis are in it.
>
Hi Jerry:
I think the above change will screw up our installed Ada examples
build which exclusively uses the gnatmake approach. So please test
the installed examples build with and without the above change to see
whether that hypothesis is correct.
To remind you how to do such testing do your normal procedure
for building and installing PLplot. Then
run cmake in an empty directory
with no options and with just a reference to the installed examples
tree like this:
# insures initially empty build tree.
rm -rf test_install_build
mkdir test_install_build
cd test_install_build
cmake /usr/local/plplot/share/plplot5.9.9/examples
then
make test_ada_psc
That make command should work fine for an unmolested install, but if
you move install tree files around and repeat the above commands
(again for an initially empty build directory) I predict it won't
work.
To me it would make a lot of sense if you configured the GPR build
process for your own use (as opposed to the PLplot build system which
uses gnatmake exclusively) so that it followed the traditional gnatmake
location conventions (as the PLplot core build, install, and installed
examples build processes do now).
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

On May 9, 2012, at 2:27 PM, Alan W. Irwin wrote:
> On 2012-05-09 01:36-0700 Jerry wrote:
>
>> I recently updated my Ada compiler from the 2010 GPL version provided by Adacore (the commercial source) to the 2011 version and encountered a rather odd problem when trying to link the Ada bindings into my own project.
>>
>> GCC Ada aka GNAT and its tools provide two systems of building stuff--the older and still-used one uses the gnatmake and related commands, providing a somewhat traditional way of passing arguments on to the gcc tools.
>>
>> The other system is called GPR (Gnat PRoject), gprbuild, and one writes some relatively sane-looking files that do the same thing as gnatmake et al and more. This is the system that I have used, in very simple ways.
>>
>> I don't know if what I'll describe in a bit is necessary for gnatmake but is seems so for gprbuild. It is a complete mystery why this worked for the 2010 tools at all without the following change, which I believe we should incorporate into the PLplot build. It's really simple.
>>
>> Copy
>>
>> /usr/local/plplot/lib/libplplotadad.0.0.0.dylib
>> /usr/local/plplot/lib/libplplotadad.0.dylib
>> /usr/local/plplot/lib/libplplotadad.dylib
>>
>> to
>>
>> /usr/local/plplot/lib/ada/adalib/plplotadad
>>
>> where /usr/local/plplot is my installation directory. That's it. When I do this manually, my personal stuff builds using the 2011 tools, but if I don't do it the 2011-tool build fails. There are some other files in the target directory, ending in .ali--these should remain--the .dylib needs to be in the same folder as these .ali. I suppose another directory would suffice as long as the .dylib and .alis are in it.
>>
>
> Hi Jerry:
>
> I think the above change will screw up our installed Ada examples
> build which exclusively uses the gnatmake approach. So please test
> the installed examples build with and without the above change to see
> whether that hypothesis is correct.
>
> To remind you how to do such testing do your normal procedure
> for building and installing PLplot. Then
> run cmake in an empty directory
> with no options and with just a reference to the installed examples
> tree like this:
>
> # insures initially empty build tree.
> rm -rf test_install_build
> mkdir test_install_build
> cd test_install_build
>
> cmake /usr/local/plplot/share/plplot5.9.9/examples
>
> then
>
> make test_ada_psc
>
> That make command should work fine for an unmolested install, but if
Hmm.... I did this
cd /usr/local/dumpme
rm -rf test_install_build
mkdir test_install_build
cd test_install_build
cmake /usr/local/plplot/share/plplot5.9.9/examples
make test_ada_psc
and got this...
Generate ada results for psc device
Testing front-end ada
x01
/usr/local/plplot/share/plplot5.9.9/examples/test_ada.sh: line 32: 34044 Trace/BPT trap: 5 "$adadir"/x${index}${lang} -dev $device -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >|"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
dyld: Library not loaded: @rpath/libgnat-2010.dylib
Referenced from: /usr/local/dumpme/test_install_build/./ada/x01a
Reason: image not found
make[3]: *** [x01a.psc] Error 1
make[2]: *** [CMakeFiles/test_ada_psc.dir/all] Error 2
make[1]: *** [CMakeFiles/test_ada_psc.dir/rule] Error 2
make: *** [test_ada_psc] Error 2
I tried to supply the path to what I think it is asking for but I'm not sure how to do that.
> you move install tree files around and repeat the above commands
> (again for an initially empty build directory) I predict it won't
> work.
>
> To me it would make a lot of sense if you configured the GPR build
> process for your own use
As I understand it, to use gprbuild, the library (.dylib on OS X, or .a if built that way) needs to be in the same directory as the .ali files. I also think that an alternative to linking to the .dylib would be to designate a directory that contains all of the bindings' .ali and .o files which (as of now) is
/usr/local/plplot_build_dir/bindings/ada/CMakeFiles/plplotadad.dir
> (as opposed to the PLplot build system which
> uses gnatmake exclusively) so that it followed the traditional gnatmake
> location conventions (as the PLplot core build, install, and installed
> examples build processes do now).
I understand what you're saying, but I think that gprbuild is just a layer over gcc like gnatmake. In any case, it would be of use to users to be able to use gprbuild if they wish. How can _copying_ these files mess with the current build process for the examples?
I'm still hoping for more help on general library issues from comp.lang.ada--the GPS docs are not the finest example of technical writing and seem especially vague on this topic.
Jerry
>
> Alan

On 2012-05-10 00:59-0700 Jerry wrote:
>> Hi Jerry:
>>
>> I think the above change will screw up our installed Ada examples
>> build which exclusively uses the gnatmake approach. So please test
>> the installed examples build with and without the above change to see
>> whether that hypothesis is correct.
>>
>> To remind you how to do such testing do your normal procedure
>> for building and installing PLplot. Then
>> run cmake in an empty directory
>> with no options and with just a reference to the installed examples
>> tree like this:
>>
>> # insures initially empty build tree.
>> rm -rf test_install_build
>> mkdir test_install_build
>> cd test_install_build
>>
>> cmake /usr/local/plplot/share/plplot5.9.9/examples
>>
>> then
>>
>> make test_ada_psc
>>
>> That make command should work fine for an unmolested install, but if
>
> Hmm.... I did this
>
> cd /usr/local/dumpme
> rm -rf test_install_build
> mkdir test_install_build
> cd test_install_build
> cmake /usr/local/plplot/share/plplot5.9.9/examples
> make test_ada_psc
>
>
> and got this...
>
>
> Generate ada results for psc device
> Testing front-end ada
> x01
> /usr/local/plplot/share/plplot5.9.9/examples/test_ada.sh: line 32: 34044 Trace/BPT trap: 5 "$adadir"/x${index}${lang} -dev $device -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >|"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
> dyld: Library not loaded: @rpath/libgnat-2010.dylib
> Referenced from: /usr/local/dumpme/test_install_build/./ada/x01a
> Reason: image not found
> make[3]: *** [x01a.psc] Error 1
> make[2]: *** [CMakeFiles/test_ada_psc.dir/all] Error 2
> make[1]: *** [CMakeFiles/test_ada_psc.dir/rule] Error 2
> make: *** [test_ada_psc] Error 2
>
>
> I tried to supply the path to what I think it is asking for but I'm not sure how to do that.
Hi Jerry:
I am not familiar with the Mac OS X platform, but from the message above
it looks to me like
the run-time loader that executes x01a is having trouble locating
libgnat-2010.dylib in your new installation. Isn't there a standard
environment variable you can set (LD_LIBRARY_PATH works for Linux) to
help address such issues?
I assume you would get the same error for the core build system as
well, but to check that do a clean _core_ build of PLplot using
the cmake option, -DBUILD_TEST=ON
then run
make test_ada_psc
as above. But this will be in the build tree of the core build rather
than the build tree of the installed examples. Of course, if the
core build version works while the above installed example version
does not, then compare exact commands that are run in each case using
make VERBOSE=1 test_ada_psc
But I am virtually positive you will get the same result for core
build and installed examples build since virtually the same CMake code
is used in both cases.
By the way, the test_ada_psc target runs the Ada subset of what is
done for all language bindings and examples with the
test_noninteractive target. And if I recall correctly you have run
that test_noninteractive target in the past with no issues. Once this
current "run time loader cannot find Ada system library" issue is
addressed for your current Ada installation, I strongly encourage you
to run the test_noninteractive target (or at least the Ada subset of
that test with the target name "test_ada_psc") more often so that
_every_ system and PLplot change is tested right after the change
occurs (rather than days or months later when you have forgotten the
details of the change).
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote:
> On 2012-05-10 00:59-0700 Jerry wrote:
>
>>> Hi Jerry:
>>>
>>> I think the above change will screw up our installed Ada examples
>>> build which exclusively uses the gnatmake approach. So please test
>>> the installed examples build with and without the above change to see
>>> whether that hypothesis is correct.
>>>
>>> To remind you how to do such testing do your normal procedure
>>> for building and installing PLplot. Then
>>> run cmake in an empty directory
>>> with no options and with just a reference to the installed examples
>>> tree like this:
>>>
>>> # insures initially empty build tree.
>>> rm -rf test_install_build
>>> mkdir test_install_build
>>> cd test_install_build
>>>
>>> cmake /usr/local/plplot/share/plplot5.9.9/examples
>>>
>>> then
>>>
>>> make test_ada_psc
>>>
>>> That make command should work fine for an unmolested install, but if
>>
>> Hmm.... I did this
>>
>> cd /usr/local/dumpme
>> rm -rf test_install_build
>> mkdir test_install_build
>> cd test_install_build
>> cmake /usr/local/plplot/share/plplot5.9.9/examples
>> make test_ada_psc
>>
>>
>> and got this...
>>
>>
>> Generate ada results for psc device
>> Testing front-end ada
>> x01
>> /usr/local/plplot/share/plplot5.9.9/examples/test_ada.sh: line 32: 34044 Trace/BPT trap: 5 "$adadir"/x${index}${lang} -dev $device -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error >|"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
>> dyld: Library not loaded: @rpath/libgnat-2010.dylib
>> Referenced from: /usr/local/dumpme/test_install_build/./ada/x01a
>> Reason: image not found
>> make[3]: *** [x01a.psc] Error 1
>> make[2]: *** [CMakeFiles/test_ada_psc.dir/all] Error 2
>> make[1]: *** [CMakeFiles/test_ada_psc.dir/rule] Error 2
>> make: *** [test_ada_psc] Error 2
>>
>>
>> I tried to supply the path to what I think it is asking for but I'm not sure how to do that.
>
> Hi Jerry:
>
> I am not familiar with the Mac OS X platform, but from the message above
> it looks to me like
> the run-time loader that executes x01a is having trouble locating
> libgnat-2010.dylib in your new installation.
I've puzzled over @rpath before--can't remember what I learned but I don't think it was much.
> Isn't there a standard
> environment variable you can set (LD_LIBRARY_PATH works for Linux) to
> help address such issues?
>
> I assume you would get the same error for the core build system as
> well, but to check that do a clean _core_ build of PLplot using
> the cmake option, -DBUILD_TEST=ON
I always do.
>
> then run
>
> make test_ada_psc
What do I cd to before running this?
BTW the results that I reported before were with the 2010 compiler but the 2011 compiler makes the exact same output but with
dyld: Library not loaded: @rpath/libgnat-2011.dylib
^
All for tonight (U.S. west)
Jerry
>
> as above. But this will be in the build tree of the core build rather
> than the build tree of the installed examples. Of course, if the
> core build version works while the above installed example version
> does not, then compare exact commands that are run in each case using
>
> make VERBOSE=1 test_ada_psc
>
> But I am virtually positive you will get the same result for core
> build and installed examples build since virtually the same CMake code
> is used in both cases.
>
> By the way, the test_ada_psc target runs the Ada subset of what is
> done for all language bindings and examples with the
> test_noninteractive target. And if I recall correctly you have run
> that test_noninteractive target in the past with no issues. Once this
> current "run time loader cannot find Ada system library" issue is
> addressed for your current Ada installation, I strongly encourage you
> to run the test_noninteractive target (or at least the Ada subset of
> that test with the target name "test_ada_psc") more often so that
> _every_ system and PLplot change is tested right after the change
> occurs (rather than days or months later when you have forgotten the
> details of the change).
>
> Alan

On 2012-05-10 03:18-0700 Jerry wrote:
>
> On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote:
>> Hi Jerry:
>>
>> I am not familiar with the Mac OS X platform, but from the message above
>> it looks to me like
>> the run-time loader that executes x01a is having trouble locating
>> libgnat-2010.dylib in your new installation.
>
> I've puzzled over @rpath before--can't remember what I learned but I don't think it was much.
>
>> Isn't there a standard
>> environment variable you can set (LD_LIBRARY_PATH works for Linux) to
>> help address such issues?
>>
>> I assume you would get the same error for the core build system as
>> well, but to check that do a clean _core_ build of PLplot using
>> the cmake option, -DBUILD_TEST=ON
>
> I always do.
>>
>> then run
>>
>> make test_ada_psc
>
> What do I cd to before running this?
You run that target exactly the way your run the test_noninteractive
target, i.e., you cd to the top of the (empty) build tree for the core
build (or equivalent installed examples build), run cmake there, then
run "make test_ada_psc" there.
But if test_ada_psc does not work, neither will test_noninteractive
since the latter executes the test_ada_psc target (and a whole lot
more). The advantage of test_ada_psc, of course, is it just
concentrates on testing the Ada build and Ada examples so it is much
quicker than the far more comprehensive test_noninteractive target.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________

OK--I got some great help from comp.lang.ada (as usual) and have learned how to make a .gpr file that references the .ali files and the corresponding .dylib when they are in separate directories. My original problem is solved in that I can now build PLplot using the 2011 GNAT (from an old version of source--not to confuse this thread with my other pending thread on the list) and subsequently bind and link my personal project.
I was pointed to a very nice document called Debian policy for Ada at
http://people.debian.org/~lbrenta/debian-ada-policy.html
which provided a clearer description of what needed to be done than the GPRbuild User's Guide.
It's still a mystery why my defective .gpr file worked with the 2010 GNAT tools.
Unless Alan thinks we have uncovered some testing issues, I'm ready to put this to rest.
Sorry for the fuss.
Jerry
On May 10, 2012, at 11:12 AM, Alan W. Irwin wrote:
> On 2012-05-10 03:18-0700 Jerry wrote:
>
>>
>> On May 10, 2012, at 1:34 AM, Alan W. Irwin wrote:
>>> Hi Jerry:
>>>
>>> I am not familiar with the Mac OS X platform, but from the message above
>>> it looks to me like
>>> the run-time loader that executes x01a is having trouble locating
>>> libgnat-2010.dylib in your new installation.
>>
>> I've puzzled over @rpath before--can't remember what I learned but I don't think it was much.
>>
>>> Isn't there a standard
>>> environment variable you can set (LD_LIBRARY_PATH works for Linux) to
>>> help address such issues?
>>>
>>> I assume you would get the same error for the core build system as
>>> well, but to check that do a clean _core_ build of PLplot using
>>> the cmake option, -DBUILD_TEST=ON
>>
>> I always do.
>>>
>>> then run
>>>
>>> make test_ada_psc
>>
>> What do I cd to before running this?
>
> You run that target exactly the way your run the test_noninteractive
> target, i.e., you cd to the top of the (empty) build tree for the core
> build (or equivalent installed examples build), run cmake there, then
> run "make test_ada_psc" there.
>
> But if test_ada_psc does not work, neither will test_noninteractive
> since the latter executes the test_ada_psc target (and a whole lot
> more). The advantage of test_ada_psc, of course, is it just
> concentrates on testing the Ada build and Ada examples so it is much
> quicker than the far more comprehensive test_noninteractive target.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________