octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ubuntu osmesa problems


From: Mike Miller
Subject: Re: Ubuntu osmesa problems
Date: Mon, 14 Dec 2015 12:39:40 -0500
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Dec 14, 2015 at 17:32:05 +0100, Andreas Weber wrote:
> Am 14. Dezember 2015 17:23:24 MEZ, schrieb Mike Miller <address@hidden>:
> >Andy (and all),
> >
> >It's been confirmed that a recent update to the Ubuntu packaging of
> >OSMesa breaks the __osmesa_print__ function in Octave, and not just for
> >Nvidia users. I think this has something to do with multiple
> >conflicting
> >libGL function definitions. See bug #46675 for details.
> >
> >This only affects 14.04 users, for now, it would be nice to address
> >this
> >before 16.04 happens in a few months.
> >
> >Is there a simple non-Octave test program I can submit to the Ubuntu
> >bug
> >tracker to demonstrate the problem? Any suggestions to the Ubuntu X
> >packagers on how to address this?
> >
> >Thanks,
> >
> >-- 
> >mike
> 
> Hi Mike,
> The mesa tests have two osmesa examples which create a ppm with a
> toroid and a cone. You'll find a link in the bugtracker for "osmesa
> segfaults with nvidia" thread.
> 
> The problem is, that osmesa now includes the mesa libGL and octave
> links against osmesa and the system libGL? Would it possible to let
> Octave just use osmesa and The included libGL and not system libGL?
> This would also solve The problem with nvidia/AMD proprietary drivers.

Thanks.

If I build and run the demos, no problems.

If I run the demos with LD_PRELOAD=/usr/lib/x86_64-linux-gnu/mesa/libGL.so
I get the following wrong results printed to the screen

  $ ./osdemo32 test.tga
  channel sizes: 32765 0 0 -179813088
  depth bits 32664
  osdemo, writing tga file 
  all done

  $ ./osdemo16 test.tga
  channel sizes: 0 0 922326304 32635
  osdemo, writing tga file 
  all done

  $ ./osdemo test.tga
  Depth=-166735448 Stencil=30159656 Accum=1
  osdemo, writing tga file 
  all done

and the resulting images are just a black background.

I think this is similar to the situation in Octave, where Octave is
linked with the system libGL, then dynamically loads libOSMesa when the
__osmesa_print__.oct file is loaded.

I think the only way to prefer the libGL embedded within libOSMesa would
be to link all of Octave with libOSMesa and ensure it is loaded first,
which is not ideal.

-- 
mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]