Qhull and scripts/geometry

Jaroslav Hajek highegg at gmail.com
Tue Feb 3 06:37:39 CST 2009


On Tue, Feb 3, 2009 at 1:35 PM, Petr Mikulik <mikulik at physics.muni.cz> wrote:
>> >>> >> | Yes; configuring Qhull with
>> >>> >> |     CFLAGS="-fno-strict-aliasing -O2" ./configure $*
>> >>> >> | does not crash the testing command
>> >>> >> |      rbox c D3 | qconvex s G
>> >>> >> |
>> >>> >> | Could Octave's ./configure test the Qhull library? I propose that if the
>> >>> >> | above test command (or some C++ source test case) crashes, then Octave does
>> >>> >> | not link to Qhull library and writes a hint like
>> >>> >> |   Crashing Qhull found; please recompile the Qhull library by
>> >>> >> |     CFLAGS="-fno-strict-aliasing -O2" ./configure; make
>> >>> >>
>> >>> >> Can you provide an autoconf macro that does the test and does not
>> >>> >> require an external program?  My Debian sysstem has the library but
>> >>> >> the test programs are not installed.
>> >>> >>
>> >>> >> There is also the issue that running test programs limits the
>> >>> >> usefulness of configure scripts when cross-compiling.  In this case, I
>> >>> >> guess we would just have to assume that the library works when cross
>> >>> >> compiling.
>> >>> >
>> >>> > I've prepared the shortest code that leads to crash if the Qhull library has
>> >>> > been compiled without the appropriate CFLAGS.
>> >>> >
>> >>> > Usage:
>> >>> >    gcc -o QhullCrashTest QhullCrashTest.c -lqhull -lm
>> >>> >    echo "2 4 -0.5 -0.5 -0.5 0.5 0.5 -0.5 0.5 0.5" | ./QhullCrashTest
>> >>> >
>> >>> > If it crashes, nothing is written on stdout.
>> >>> > If it does not crash, an "OK message" is written on stdout.
>> >>> >
>> >>> > Could this testing program be used in the Octave configure?
>> >>> > I don't know how to write an autoconf macro for it.
>> >>> >
>> >>>
>> >>> Hi Petr,
>> >>>
>> >>> I'll take care of the inclusion into configure. However, for best
>> >>> suitability for autoconf macros (AC_RUN_IFELSE), please modify the
>> >>> test program in the following manner:
>> >>> 1. make the inputs part of the source
>> >>> 2. indicate success by returning exit code zero. If you can do it, to
>> >>> make the test more complete, I suggest also to check the results for
>> >>> correctness (if a crash doesn't happen on some system, but instead
>> >>> incorrect results are produced).
>> >>
>> >> I have no idea how to put the input data into the testing program.
>> >>
>> >
>> > I have taken a quick look at it and it seems the attached source is
>> > able to reproduce the crash. Would you please verify with your
>> > configuration?
>
> Yes, it reproduces the crash.
>
>> >> The success is indicated by zero exit code ("return 0"); failure is
>> >> indicated by crash with a "Segmentation fault" ... the return value seems to
>> >> be 139.
>> >
>> > Yes, this is indicated by the system (and autoconf macro handles it).
>> > I am, however, very suspicious about regarding a segfault as something
>> > predictable; it depends on the OS and perhaps other circumstances.
>> > It would be even better to check the results for correctness (see, for
>> > instance, the analogous checks for correctness of BLAS library called
>> > from Fortran); still, I'd be happy even with this. I'll turn this into
>> > a patch.
>>
>> Patch attached. Comments? OK to push?
>
> It's OK with me.
>
> Minor thing: I propose that ./configure writes a description why it has
> refused the Qhull library, for example:
>
>  Crashing Qhull library detected. Please recompile it
>  with CFLAGS="-fno-strict-aliasing -O2"
>
> ---
> Petr Mikulik
>

Good suggestion, I'll extend the patch.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


More information about the Bug-octave mailing list