bugGNU Octave - Bugs: bug #50479, __osmesa_print__ fails with mesa...

 
 

bug #50479: __osmesa_print__ fails with mesa using libglvnd, build and test suite fail

Submitter:  Michael Godfrey <godfrey>
Submitted:  Tue 07 Mar 2017 01:34:01 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  3 - Low Item Group:  Unexpected Error or Warning
Status:  Wont Fix Assigned to:  None
Originator Name:  godfrey Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 12 Jul 2018 05:38:50 PM UTC, comment #44: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/c21edcb90cbf

I don't anticipate any problems due to this change, but we can undo it if there are serious objections.

Closing this report with a "Won't Fix" status.

John W. Eaton <jwe>
Group administrator
Thu 12 Jul 2018 03:10:25 PM UTC, comment #43: 

That would suit me.  Less code to maintain and osmesa has always been a bit flaky for us.

Rik <rik5>
Group administrator
Thu 12 Jul 2018 01:43:22 PM UTC, comment #42: 

Maybe we should just remove support for osmesa?

John W. Eaton <jwe>
Group administrator
Fri 09 Mar 2018 09:05:41 PM UTC, comment #41: 

Yeah, as long as Octave is built with recent versions of Qt, Octave will use its method for offscreen printing and configure won't even look for OSMesa at all now.

Mike Miller <mtmiller>
Group Member
Fri 09 Mar 2018 08:53:12 PM UTC, comment #40: 

Now that we are using QOffscrenSurface, I'm downgrading the severity to normal and reclassifying as an unexpected error.  We no longer require or recommend using osmesa for offscren rendering, correct?

John W. Eaton <jwe>
Group administrator
Tue 07 Nov 2017 05:09:23 AM UTC, comment #39: 

Open an "issue" at https://github.com/NVIDIA/libglvnd/issues ?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Nov 2017 04:57:17 AM UTC, comment #38: 

On a system with libglvnd, if you start Octave with


__GLVND_APP_ERROR_CHECKING=1 __GLVND_ABORT_ON_APP_ERROR=0


set in the environment, then try to print with osmesa, for example, with


figure (1, 'visible', 'off')
sombrero
print sombrero.pdf


you should see the following error messages:


OpenGL function called without a current context
OpenGL function called without a current context
error: __osmesa_print__: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
error: called from
    __opengl_print__ at line 161 column 7
    print at line 552 column 14


If I understand correctly, those first two messages about calling an OpenGL function without a current context are coming from the calls to glGetIntegerv in F__osmesa_print__ and are happening because of the way libglvnd handles dispatching.

It worked previously if you were using a Mesa libGL because we linked directly to libGL and OpenGL functions were provided directly from there.  Since OSMesa uses a context that begins with the base Mesa context, those gl* calls would work.

Now, there is some magic in libglvnd to manage the pointer to the  OpenGL context and dispatch to fucntions that properly manage that context.  This works for libGL, but not libOSMesa.  So when glGetIntegerv is called no context has been created and you end up in the stub function that reports the error.

Note that making the figure visible so that a Mesa context is created does not work.  The following still fails with the same error message:


figure (1, 'visible', 'on')
sombrero
__osmesa_print__ (1, 'sombrero.pdf', 'pdf')


still fails with the same messages because although OSMesaMakeCurrent would make the context current when using the Mesa libGL, it does not do that with libglvnd so the libglvnd context is still invalid.

To fix this, it seems we need to have libOSMesa integrated with libglvnd so that the OSMesa context and dispatching for functions in libOSMesa can be properly managed by libglvnd.

It would be great if we could just ask libglvnd to create an off-screen rendering context that uses OSMesa and have it manage the function dispatch.  This should allow OSMesa to mix with any vendor OpenGL library, not just Mesa.

I've spent considerable time looking at this problem but it's still not clear to me exactly how to do that.  It appears that libglvnd maintains a table of OpenGL contexts and dispatching info for libGL functions that is indexed by X11 display and screen info.  For OSMesa, there may not be a display or screen, so some other way of storing and indexing these contexts is needed.

John W. Eaton <jwe>
Group administrator
Fri 08 Sep 2017 08:53:26 PM UTC, comment #37: 

This bug now also affects Debian unstable with the introduction of Mesa 17.2.0 and its new dependence on libglvnd.

Same workaround works on Debian unstable:


$ LD_PRELOAD=libGLX_mesa.so.0 make all
$ LD_PRELOAD=libGLX_mesa.so.0 make check


Without the LD_PRELOAD make all fails building the images under doc/interpreter and make check fails on tests that produce off-screen figures.

Using LD_PRELOAD does not seem like a solution to me.

Mike Miller <mtmiller>
Group Member
Mon 07 Aug 2017 01:43:48 PM UTC, comment #36: 

The fix for #51631 does affect this bug on Fedora 26.
Running without:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0
make check completes but reports 4 FAILs
 libinterp/dldfcn/__osmesa_print__.cc-tst .................... PASS      0/2  
                                                                  FAIL    2
and
  publish.tst ................................................. PASS      0/2  
                                                                  FAIL    2

Running with:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0
make check completes with 0 FAILS.

Michael Godfrey <godfrey>
Group Member
Fri 30 Jun 2017 10:48:24 PM UTC, comment #35: 

Just for information the bash command on Fedora 25 is:
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0.0.0

Michael Godfrey <godfrey>
Group Member
Sat 08 Apr 2017 10:08:50 PM UTC, comment #34: 

The library that is known as libGLX_mesa on Fedora is just libGL on Debian and Ubuntu distros, which is probably why this workaround isn't needed. Fedora decided to build mesa with support for the new glvnd dispatch library. Someone will have to figure out what this means for Octave's on-screen GL and off-screen OSMesa support.

Mike Miller <mtmiller>
Group Member
Sat 08 Apr 2017 04:33:47 PM UTC, comment #33: 

Dmitri's workaround does work for me too. Is there
a more general way to fix this? Or, should this
workaround be integrated in the startup?

And, the build of the documentation still fails.

My glxinfo |grep -i mesa is:

[godfrey@pbdsl4 ~]$ glxinfo | grep -i mesa
12:    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
15:client glx vendor string: Mesa Project and SGI
25:    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
26:    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
27:    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
39:    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
40:    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
41:    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control,
45:Extended renderer info (GLX_MESA_query_renderer):
47:    Device: Mesa DRI Intel(R) HD Graphics 6000 (Broadwell GT3)  (0x1626)
58:OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 6000 (Broadwell GT3)
59:OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.4
139:    GL_MESA_pack_invert, GL_MESA_shader_integer_functions,
140:    GL_MESA_texture_signed_rgba, GL_NV_conditional_render, GL_NV_depth_clamp,
144:OpenGL version string: 3.0 Mesa 13.0.4
239:    GL_MESA_pack_invert, GL_MESA_shader_integer_functions,
240:    GL_MESA_texture_signed_rgba, GL_MESA_window_pos, GL_NV_blend_square,
249:OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.4
271:    GL_MESA_shader_integer_functions, GL_NV_draw_buffers,


Michael Godfrey <godfrey>
Group Member
Sat 08 Apr 2017 09:02:50 AM UTC, comment #32: 
Dmitri A. Sergatskov <dasergatskov>
Sat 08 Apr 2017 08:56:57 AM UTC, comment #31: 

It looks to me that the issue is osmesa conflicts with some other
mesa libs. The only workaround I found it to
LD_PRELOAD==/usr/lib64/libGLX_mesa.so.0.0.0
prior to running octave.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Apr 2017 08:43:21 AM UTC, comment #30: 

The test for depth_bits and stencil_bits was a clumsy attempt to check if the OSMesa stuff is working. The code before the test tries to set depth and stencil bits to 16 and 0 and if the readed values matches I thought this would be an indication that something goes wrong...

After all, if you disable the test (comment the lines) is osmesa working for you?

You wrote that GL_DEPTH_BITS is "54" on your system which looks to me that this is just a value read from the wrong memory address due to incompatible libraried.

Also make sure that you are using a Mesa based GPU driver.


glxinfo | grep -i mesa


Andreas Weber <andy1978>
Group Member
Sat 08 Apr 2017 01:45:28 AM UTC, comment #29: 

I looked at this a bit and edited _osomesa_print_.cc:

  if (z != 16 || s != 0)
    error ("__osmesa_print__: Depth and stencil doesn't match,"
           " are you sure you are using OSMesa >= 9.0? GL_DEPTH_BITS \"%i\" GL_STENCIL_BITS \"%i\"", z, s);
and ran this and got:
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0? GL_DEPTH_BITS "54" GL_STENCIL_BITS "0"

So, GL_DEPTH_BITS = 54 is the problem.


Michael Godfrey <godfrey>
Group Member
Sat 08 Apr 2017 12:04:21 AM UTC, comment #28: 

This error is, of course, due to the
GL_DEPTH_BITS and
GL_STENCIL_BITS
in the latest osmesa. The test that fails is
at line 145 of --osmesa_print__.cc
someone with osmesa knowledge is needed to fix this.
Owner: Copyright (C) 2016-2017 Andreas Weber <andy.weber.aw@gmail.com>

Michael Godfrey <godfrey>
Group Member
Thu 06 Apr 2017 05:08:24 PM UTC, comment #27: 

Finally, here is what confused my make install:
With the current build it is necessary to run
make -i install
This has the side effect of leaving a large number of
files with owner root. This then prevents subsequent
makes from functioning "correctly".

So, the remaining problem is as originally stated:

error: osmesa_print: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?

Michael Godfrey <godfrey>
Group Member
Tue 04 Apr 2017 02:04:51 AM UTC, comment #26: 

My previous entry is not quite accurate. I just did
a clean build and the failure due to osmesa version has
returned as Dmitri reported. For the build to complete
I had to do: make -i and no documentation was generated
in doc/interpreter.

But, if I run:
./run-octave --no-gui
randn("state",1);
hist(randn (10000,1),30)
graphics_toolkit
ans = fltk
========================
I get a correct histogram as I did with the previous system.
And, as before print xxhist.pdf produces the diagonal lines.
So, now I have no explanation of how my build system
started to complete using gnuplot.


Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 03:37:13 AM UTC, comment #25: 

I just run ./configure
and I did a clean rebuild recently.
It appeared that this was what fixed it for me. But,...

The unexplained behavior is that I have osmesa and the
build uses it, and that works, but the build of the
/doc/interpreter stuff uses gnuplot!!!
I think that there was a change in the build script
to use gnuplot even though osmesa and everything that
fltk and qt needs are available.

However, this does not explain Dmitri's problem.

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 03:20:49 AM UTC, comment #24: 

Did you run
./configure --without-osmesa

?

Remove your build tree, re-sync and re-build.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 03:12:23 AM UTC, comment #23: 

Also,
On my system:
[godfrey@pbdsl4 octave]$ rpm -qa|grep -i osmesa
399:mesa-libOSMesa-devel-13.0.4-3.fc25.x86_64
2487:mesa-libOSMesa-13.0.4-3.fc25.x86_64
[godfrey@pbdsl4 octave]$

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 03:09:04 AM UTC, comment #22: 

Mike,
In my installed octave I get:
octave:1> _have_feature_ ("OSMESA")
ans = 1
octave:2>

But, the build switches to gnuplot...

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 03:02:16 AM UTC, comment #21: 

Michael - what does


>> __have_feature__ ("OSMESA")


return in your current build of Octave? If it returns false, then the build will automatically switch to gnuplot for building the plot images under doc/interpreter.

Mike Miller <mtmiller>
Group Member
Mon 03 Apr 2017 02:23:30 AM UTC, comment #20: 

Dimitri,

OK. Here is what I get:

octave:1> randn("state",1);
octave:2> hist(randn (10000,1),30)
octave:3> graphics_toolkit
ans = fltk
octave:4> print histxx.pdf
octave:5> graphics_toolkit
ans = fltk
=========================
The displayed plot is OK.
The result of print histxx.pdf shows the diagonal
lines.

So, it appears that the build uses gnuplot at least
for some of the plots (some fail with gnuplot).

It was not a good idea to make the build dependent on gnuplot.
It would be really useful if this could be cleaned up.
But, of course, plotting has always been a major problem area.

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 02:12:14 AM UTC, comment #19: 

Interesting. I did not switch. Something in the
build scripts made that choice. I will try the histogram
outside of the build. My .octaverc selects fltk.

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 12:50:51 AM UTC, comment #18: 

Your file is created by gnuplot:

pdfinfo hist.pdf
Title:          /tmp/oct-D5dEHe.eps
Subject:        gnuplot plot
Author:         godfrey
Creator:        gnuplot 5.0 patchlevel 5
Producer:       GPL Ghostscript 9.20
CreationDate:   Thu Mar 30 13:12:06 2017
ModDate:        Thu Mar 30 15:12:06 2017 CDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      6711 bytes
Optimized:      no
PDF version:    1.5


Mine created by ftgl:
pdfinfo hist.pdf
Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.3.9, (C) 1999-2015 C. Geuzaine
Producer:       GPL Ghostscript 9.20
CreationDate:   Sun Apr  2 19:49:21 2017 CDT
ModDate:        Sun Apr  2 19:49:21 2017 CDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      4286 bytes
Optimized:      no
PDF version:    1.5

Somehow you switched to using gnuplot as the default backend.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 12:46:18 AM UTC, comment #17: 

Dmitri,
You might check the time stamp on your hist.pdf.
The error that you are getting will, I think, prevent it
from being created by the build that fails.

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 12:36:36 AM UTC, comment #16: 

My hist.pdf is attached.
And, my hg id matches your.

Looking quickly, your system seems much like mine.
The hardware is surely different but hard to see why that
would matter.

(file #40239)

Michael Godfrey <godfrey>
Group Member
Mon 03 Apr 2017 12:23:54 AM UTC, comment #15: 

Also:

rpm -qa | grep mesa
mesa-libGLw-8.0.0-8.fc24.x86_64
mesa-libGLES-13.0.4-3.fc25.x86_64
mesa-libEGL-13.0.4-3.fc25.x86_64
mesa-libGLw-devel-8.0.0-8.fc24.x86_64
mesa-libGLU-9.0.0-10.fc24.x86_64
mesa-libEGL-devel-13.0.4-3.fc25.x86_64
mesa-libglapi-13.0.4-3.fc25.x86_64
mesa-libGLES-devel-13.0.4-3.fc25.x86_64
mesa-libwayland-egl-devel-13.0.4-3.fc25.x86_64
mesa-filesystem-13.0.4-3.fc25.x86_64
mesa-libxatracker-13.0.4-3.fc25.x86_64
mesa-libGL-13.0.4-3.fc25.x86_64
mesa-libgbm-devel-13.0.4-3.fc25.x86_64
mesa-libgbm-13.0.4-3.fc25.x86_64
mesa-libGL-devel-13.0.4-3.fc25.x86_64
mesa-libGLU-devel-9.0.0-10.fc24.x86_64
mesa-libxatracker-devel-13.0.4-3.fc25.x86_64
mesa-dri-drivers-13.0.4-3.fc25.x86_64
mesa-libwayland-egl-13.0.4-3.fc25.x86_64
mesa-vulkan-drivers-13.0.4-3.fc25.x86_64
mesa-libOpenCL-devel-13.0.4-3.fc25.x86_64
mesa-libOSMesa-devel-13.0.4-3.fc25.x86_64
mesa-libd3d-devel-13.0.4-3.fc25.x86_64
mesa-libd3d-13.0.4-3.fc25.x86_64
mesa-libOSMesa-13.0.4-3.fc25.x86_64
mesa-libOpenCL-13.0.4-3.fc25.x86_64

....

make[2]: Entering directory '/home/dima/src/octave/gcc_default'
  GEN      etc/icons/octave-logo-256.png
  GEN      etc/icons/octave-logo-48.png
  GEN      etc/icons/octave-logo-32.png
  GEN      etc/icons/octave-logo-16.png
  TEXI2PDF doc/liboctave/liboctave.pdf
  PDFTEX   doc/refcard/refcard-a4.pdf
  PDFTEX   doc/refcard/refcard-legal.pdf
  PDFTEX   doc/refcard/refcard-letter.pdf
  GEN      etc/icons/octave-logo-512.png
  GEN      etc/icons/octave-logo-128.png
  GEN      etc/icons/octave-logo-64.png
  GEN      etc/icons/octave-logo-24.png
  GEN      etc/icons/octave-logo-22.png
  GEN      etc/icons/octave-logo.ico
  GEN      doc/interpreter/voronoi.eps
  GEN      doc/interpreter/triplot.eps
  GEN      doc/interpreter/griddata.eps
  GEN      doc/interpreter/convhull.eps
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
Makefile:27871: recipe for target 'doc/interpreter/triplot.eps' failed
make[2]: * [doc/interpreter/triplot.eps] Error 1
make[2]: * Waiting for unfinished jobs....
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
Makefile:27875: recipe for target 'doc/interpreter/convhull.eps' failed
make[2]: * [doc/interpreter/convhull.eps] Error 1
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?
<...etc...>

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Mon 03 Apr 2017 12:10:31 AM UTC, comment #14: 

yes and yes.
hg id
68dbde0e670a tip @

Could you send me yours hist.pdf?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sun 02 Apr 2017 10:55:04 PM UTC, comment #13: 

Dmitri,

Are you using Fedora 25 with latest updates, or
equivalent? And, mesa libraries at 13.0.4-3?

Of course, it may have been something else that
fixed the problem for me...

And, are you using latest Octave updates?

Yes, 15.2 is the histogram. I suspect that it is an
Octave fix that fixed this, so check that you have
latest Octave fixes.

Michael Godfrey <godfrey>
Group Member
Sun 02 Apr 2017 08:05:35 PM UTC, comment #12: 

I still have to LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 priot to make and the histogram pdf (I assume this is the Figure 15.2) still has diagonal dashed lines inside the bars (attached).

Dmitri.

(file #40236)

Dmitri A. Sergatskov <dasergatskov>
Sun 02 Apr 2017 06:32:37 PM UTC, comment #11: 

I have not seen a patch which fixed this problem,
but as of recent Fedora updates the problem is,
for me, gone.

So, if this was just a Fedora transient, the report
can be closed.

And, separately, the Figure 15.2 now displays
correctly! This must have been fixed by one of the
recent plotting code updates. (This is using  FLTK.)

Michael Godfrey <godfrey>
Group Member
Wed 22 Mar 2017 05:27:04 PM UTC, comment #10: 

It would be best to fix this bug so that users can use
print with visible off while using the osmesa dependent
graphics_toolkits. This would also fix the documentation
build problem. Users face the same problem as the build
when using scripts tp generate many plots: having each plot
pop up on the screen is not usually helpful.

Falling back to gnuplot is not a good choice either for
system build of for users.

Michael Godfrey <godfrey>
Group Member
Wed 22 Mar 2017 07:44:20 AM UTC, comment #9: 

One workaround is to do

LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 make

(and
LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 make check
)

Could the same be achieved by changing linking order
(in the Makefile)?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 21 Mar 2017 07:02:48 PM UTC, comment #8: 

The build uses "visible" = "off" so that plots do not pop up on the user's display while building Octave. Building the figures for the manual is part of the (maintainer) build, and it was decided that it should not open new windows or move focus away from the terminal or from anything else the user might be doing while the build is running.

Building without OSMesa (--without-osmesa) or without OpenGL (--without-opengl) forces the doc/interpreter build rules to drop back to using gnuplot to generate the figures for the manual.

Mike Miller <mtmiller>
Group Member
Mon 20 Mar 2017 09:27:07 AM UTC, comment #7: 

Dmitri,

Correct, but many scripts are set to use "visible off"
since there was an extended period when only this worked.
This is why the build uses "visible off". And, there must
have been a time when osomega was needed with visible off,
but there also was a time when this was not true.

Still a bug worth fixing. But, it appears to be an osomega
problem. Someone with more knowledge of osomega is needed
to find where/how it can be fixed.

Michael Godfrey <godfrey>
Group Member
Mon 20 Mar 2017 01:27:42 AM UTC, comment #6: 

I thought osmesa only needed if you want to produce prints w/o
actual plot (on a headless server e.g.).
A more common plot/print sequence seems to work fine...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Mar 2017 12:06:07 AM UTC, comment #5: 

I should have added that plots work, but print does
not. Thus, no .pdf files can be generated for example.

Michael Godfrey <godfrey>
Group Member
Mon 20 Mar 2017 12:03:42 AM UTC, comment #4: 

This error also affects the 4.0.3 release on Fedora 25
if Fedora has been updated to current osmesa. So, it is
more serious.

Michael Godfrey <godfrey>
Group Member
Sun 12 Mar 2017 12:34:06 PM UTC, comment #3: 

I get the same under Arch Linux. We recently got an update of the mesa infrastructure similar to the one Fedora got.

Stefan Husmann <haawda>
Tue 07 Mar 2017 08:41:24 PM UTC, comment #2: 

It is the same error message we have on ubuntu 14.04.2: see https://bugs.launchpad.net/ubuntu/trusty/+source/mesa/+bug/1424059

Pantxo Diribarne <pantxo>
Group Member
Tue 07 Mar 2017 03:49:54 PM UTC, comment #1: 

I can confirm that.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 07 Mar 2017 01:34:01 PM UTC, original submission:  

After recent update of Fedora 25 I get during build:
error: _osmesa_print_: Depth and stencil doesn't match, are you sure you are using OSMesa >= 9.0?

The current mesa version is: 13.0.4-1

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #40239:  hist.pdf added by godfrey (7KiB - application/pdf)
file #40236:  hist.pdf added by dasergatskov (4KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by haawda (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by godfrey (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-07-12 jwe StatusConfirmed Wont Fix
        Open/ClosedOpen Closed
    2018-07-11 rik5 Priority5 - Normal 3 - Low
    2018-03-09 jwe Severity4 - Important 3 - Normal
        Item GroupRegression Unexpected Error or Warning
    2018-02-02 mtmiller Dependencies- bugs #52436 is dependent
    2017-09-08 mtmiller Severity3 - Normal 4 - Important
        Summarybuild fails on osmesa print _osmesa_print_ fails with mesa using libglvnd, build and test suite fail
    2017-04-03 godfrey Attached File- Added hist.pdf, #40239
    2017-04-02 dasergatskov Attached File- Added hist.pdf, #40236
    2017-03-07 pantxo StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code