bugGNU Octave - Bugs: bug #49138, FLTK found at configure but all...

 
 

bug #49138: FLTK found at configure but all fltk toolkit tests fail

Submitter:  Carlo de Falco <cdf>
Submitted:  Tue 20 Sep 2016 01:13:12 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.0-rc1 Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 15 Mar 2017 11:19:59 PM UTC, comment #12: 

Per comment #10, all of the Java tests could have a run time check.  For example, the cross-build of MXE Octave for Windows includes Java functionality (available at compile time).  But the PC where Octave is installed might not have a JRE.

As an example, see javachk.m


%!testif HAVE_JAVA
%! if (! usejava ("jvm"))
%!   return;
%! endif
%! assert (javachk ("jvm"), "");


A number of the functions like java_set or java_get have no BIST tests because there was no good way make tests conditional on the presence of a JVM.

Rik <rik5>
Group administrator
Wed 15 Mar 2017 08:07:26 PM UTC, comment #11: 

I checked in the following change to allow run-time conditions to determine whether to skip a test.

http://hg.savannah.gnu.org/hgweb/octave/rev/67d741321e21

The changeset also updates the 10 cases the Rik identified.  Are there others?

John W. Eaton <jwe>
Group administrator
Fri 23 Sep 2016 04:06:55 PM UTC, comment #10: 

I prefaced the 10 tests that depend at runtime on a working window environment with


%! if (! have_window_system)
%!  return;
%! endif


I'm not going to tackle the larger question of how to get these tests reported as XFAILs.  That question needs to be answered for the Java tests as well, and it makes sense to address both cases at the same time.

Rik <rik5>
Group administrator
Thu 22 Sep 2016 07:53:44 AM UTC, comment #9: 

I cannot think of a way of marking a test as XFAIL at runtime
but what we could do is to add


%! if (! have_window_system)
%!  error ("This test cannot be performed if Octave is run without a window system")
%! endif


to all FLTK tests so at least the reason for the failure is clear.

As Rik noted the tests that require this are few enough that we can do it manually.

Carlo de Falco <cdf>
Group Member
Wed 21 Sep 2016 04:46:45 PM UTC, comment #8: 

Agree, we do need a way to differentiate between a test that is disabled because we know it would fail (such as --without-foo-feature), and a test that fails because of some run time condition that we may not have expected.

The latter are more similar to XFAILS, they are expected failures, but not because of a bug, because of some external condition like not having a display, or not having a home directory, or not having internet access.

We do want to see that the test failed, and why it failed, which is what is shown now, but it would also be nice to be able to more easily see that they are not failures due to a real problem in Octave or in some external library.

Mike Miller <mtmiller>
Group Member
Wed 21 Sep 2016 04:37:37 PM UTC, comment #7: 

There are 3 testif HAVE_FLTK in the libinterp directory and 7 in the scripts directory.  The number is not large so they could be retrofitted with a run-time test, perhaps using have_window_system, to decide whether they should be executed.

But that still feels like the wrong strategy.  If 'make check' is being run to test for regressions on several different platforms then we would like it to run the graphical tests, not just skip them.


Rik <rik5>
Group administrator
Wed 21 Sep 2016 04:35:12 PM UTC, comment #6: 

Mike,
you are right, if I ssh with no remote display


available_graphics_toolkits
ans =
{
  [1,1] = gnuplot
}


and


have_window_system
ans = 0


skipping the tests would make sense to me and it is probably
as simple as checking if have_window_system is true ...

c.


Carlo de Falco <cdf>
Group Member
Wed 21 Sep 2016 04:28:09 PM UTC, comment #5: 

So that seems consistent with what I am thinking is happening.

The available_graphics_toolkits will not list fltk if have_window_system returns false, and I think that's what happens in the buildbot environment.

When you remote in to test it manually, it probably works because there is a display available, either local or remotely. To get these tests to pass would need a VNC or other headless display to dump figures to.

I guess disabling the tests would be an option, similar to what we discussed about Java tests that have "testif HAVE_JAVA", but fail when the JVM is not actually available at run time.

Mike Miller <mtmiller>
Group Member
Wed 21 Sep 2016 08:41:22 AM UTC, comment #4: 

Hi, thanks for all your replies ...

@Rik

available_graphics_toolkits

does list fltk whether I add the library location to
LD_LIBRARY_PATH or not (which is actually called DYLD_LIBRARY_PATH on OSX, btw).

graphics_toolkit fltk
plot (randn (5))

does produce a plot (although extremely slow, but that may be due to remote connection?)

@Mike

The issue here is that FLTK test are NOT suppressed,
all tests prepended with testif HAVE_FLTK are run but fail,
if FLTK cannot access a display maybe they should be skipped?

Xvfb cannot be used as we we link to the aqua version (not x11)
of FLTK and QT

I think a headless display can be produced with VNC as well but
I don't remeber how, I'll look into this.

Carlo de Falco <cdf>
Group Member
Tue 20 Sep 2016 04:21:21 PM UTC, comment #3: 

On the Debian builds, we install the "xvfb" package and run make check with DISPLAY set to an Xvfb running in the background. If there is a xvfb package available in homebrew we should set that up also.

Mike Miller <mtmiller>
Group Member
Tue 20 Sep 2016 04:20:13 PM UTC, comment #2: 

Carlo - if you ssh in to the mac mini and try to test fltk with a VNC or with X protocol forwarding over ssh, does it work? I think the tests you are seeing skipped are simply because the build environment has no DISPLAY variable.

I get the same results on Debian when I run


$ DISPLAY= make check


These messages that Octave normally produces


octave: X11 DISPLAY environment variable not set
octave: disabling GUI features


are suppressed when running make check.

Mike Miller <mtmiller>
Group Member
Tue 20 Sep 2016 04:09:42 PM UTC, comment #1: 

What does this return?


available_graphics_toolkits


Is fltk one of the listed options?  Can you do a simple plot?


graphics_toolkit fltk
plot (1:10)


Since your FLTK libraries are in a non-standard location, what if you add that location to LD_LIBRARY_PATH so they can be found at runtime?

In csh syntax


setenv LD_LIBRARY_PATH /usr/local/Cellar/fltk/1.3.3/lib
./run-octave
graphics_toolkit fltk
plot (1:10)



Rik <rik5>
Group administrator
Tue 20 Sep 2016 01:13:12 PM UTC, original submission:  

Hi,

This appears again to be an inconsistency between
configure and make check on OSX:

When running configure FLTK and OpenGL appear
to be correctly detected [1]:


checking for fltk-config... /usr/local/bin/fltk-config
checking for OpenGL support in FLTK... yes


but, when running 'make check' all tests related to the
fltk toolkit fail [2]:


***** testif HAVE_OPENGL, HAVE_FLTK
 hf = figure ("visible", "off");
 graphics_toolkit (hf, "fltk");
 unwind_protect
   subplot(2,1,1); plot(rand(10,1)); subplot(2,1,2); plot(rand(10,1));
   hax = findall (gcf (), "type", "axes");
   positions = cell2mat (get (hax, "position"));
   outerpositions = cell2mat (get (hax, "outerposition"));
   looseinsets = cell2mat (get (hax, "looseinset"));
   tightinsets = cell2mat (get (hax, "tightinset"));
   subplot(2,1,1); plot(rand(10,1)); subplot(2,1,2); plot(rand(10,1));
   hax = findall (gcf (), "type", "axes");
   assert (cell2mat (get (hax, "position")), positions, 1e-4);
   assert (cell2mat (get (hax, "outerposition")), outerpositions, 1e-4);
   assert (cell2mat (get (hax, "looseinset")), looseinsets, 1e-4);
   assert (cell2mat (get (hax, "tightinset")), tightinsets, 1e-4);
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect
!!!!! test failed
graphics_toolkit: fltk toolkit is not available


the message about missing fltk toolkit seems inconsistent
with HAVE_FLTK evaluating to true ...

c.

[1] http://buildbot.octave.org:8010/builders/clang-osx/builds/23/steps/configure/logs/stdio
[2] http://www1.mate.polimi.it/~carlo/fntests.log

Carlo de Falco <cdf>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-23 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code