On Tue, Oct 03, 2017 at 01:39:32PM -0700, Mike Miller wrote: > On Tue, Oct 03, 2017 at 13:16:11 -0700, Mike Miller wrote: > > Octave team may want to discuss whether Octave should be built with > > "--without-osmesa" until a proper solution can be found upstream. > > Because it's basically a useless feature in Octave now without the > > LD_PRELOAD hack. > > Should we add "--without-OSMesa" to Octave? > > The current situation in unstable is it is completely useless for all > users with mesa >= 17.2 unless they run Octave with > "LD_PRELOAD=libGLX_mesa.so.0". > > It has previously been known to be broken in this way for users with > Nvidia hardware and proprietary drivers. This now applies to all Mesa > users. > > Background: we have been told before by Mesa upstream that having a > single executable attempt to use both Mesa libGL and OSMesa is not > supported. Octave has been doing this anyway and mostly getting away > with it. But something about the new libglvnd dispatch scheme seems to > have broken this. > > A proper upstream solution will probably involve isolating OSMesa in a > separate executable that Octave can send data to via IPC for rendering. > Other ideas for fixing this situation are very welcome. I am totally ignorant of all GL/Mesa stuff so I trust you to find the right solution. I am just wondering if an alternative to disabling OSMesa could not be to add libGLX_mesa.so.0 to the DT_NEEDED section of the octave binary (either at dynamic linking, or using patchelf --add-needed). Not that I have any kind of preference for that solution, I did not even verify that it works and is robust, just thinking… In any case, don’t hesitate to commit what seems the right fix to you. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature