[Octave-bug-tracker] [bug #44478] test __osmesa_print__.cc-tst crashes with Nvidia drivers

[Dan Sebald]

Follow-up Comment #107, bug #44478 (project octave):

Dynamically loading would probably be a solution.  Not a real good one, I
suppose.  It would mean deactivating the current graphics context altogether.

The standalone program approach would work, but I'm more partial to the
framebuffers approach for a couple reasons, after thinking about this a bit. 
First, the framebuffers is pretty seemless and doesn't require any type of
context switching.  Second, and probably the bigger reason, is that
framebuffers seems more OpenGL standard-friendly, so if there is any entity
that is likely to change direction on this it is Mesa.  They may well decide
at some point to take OSMesa and shape it into a framebuffer mold.  If that
does happen, then Octave won't have to change anything because it would find
framebuffer support in the future Mesa driver and not call
OSMesaCreateContext() which will have to have come from an older version of
Mesa at that point.

In the short term, if anything, what makes sense to me is simply creating a
version of Octave that only links in -lOSMesa and not -lGL used for creating
the documentation at build time.  Otherwise, the consequence of this problem
is small because 99% of the time I would guess the user has the figure visible
when attempting to print, and that works.  It's only when off-screen rendering
is needed for documentation that this is critical.  It would be pretty easy to
have two slightly different links.  And then if framebuffers or something else
proves to be robust, take out that build command that links only -lOSMesa to
create an octave-os.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44478>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/