Re: linking a slim liboctave without OpenGL or Nvidia stuff

[Daniel J Sebald]

On 12/21/2017 11:48 PM, Andreas Weber wrote:
> Dear all,
>
> is it feasible to compile and link a separate slim liboctave without
> OpenGL and other stuff which might influence libosmesa?
> Just enough to hgload a figure and print it.
>
> My idea is to create a standalone helper program (lets call it oct_print
> for now) which links osmesa but not the Nvidia or AMD libgl or other
> non-mesa libs)

Andy, I looked at some osmesa-related stuff quite some time ago, so I 
have forgotten exactly how it interacts with the program, but doesn't 
osmesa need some type of non-mesa, OpenGL driver to function?


> If someone wants to offscreen print a figure, print would then "hgsave"
> the figure and call oct_print which loads (or reads from stdin) the
> saved figure and uses the opengl-renderer, gl2ps (+ghostscript) and
> osmesa to create the plot.
>
> This would solve the NVIDIA libGl vs. OSMesa problematic and I also like
> the idea to have an intermediate plot exchange format.

There was a small discussion within a bigger discussion here

http://lists.gnu.org/archive/html/octave-maintainers/2017-11/msg00133.html

that illustrates how pre-loading a generic driver (as opposed to using 
the configured, custom Nvidia driver) can work with osmesa... at least 
for the build process.  E.g.,

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so make

To me, that's actually a significant accomplishment because it means not 
having to configure OSMesa from the build.

Of course, this requires the user to be cognizant of this solution, and 
it also requires that the user is on a system that has both the 
graphics-card-specific custom driver and some generic driver hanging 
around.  The latter might be fairly common, as I doubt people who 
install linux (which initially boots with a generic graphics driver) 
then their custom graphics driver will set about removing drivers they 
think are no longer needed (too much work).  The former (i.e., user 
remembering the LD_PRELOAD method) isn't so common.

But here's the good news, as I see it.  The problem that Nvidia users 
have right now is building Octave.  After the main program compile and 
link, the build process sets about compiling the manual using OSMesa 
off-screen printing.  However, that keeps failing repeatedly with every 
new "make".  My thought was that in the make/build Makefile command 
which builds the manual it could first search for the generic driver and 
pre-load that, i.e.,

1) Find some generic driver (how, I don't know but I'm sure the 
"configure" script would have some good examples of how to look for 
files), e.g.,

  GENERIC_GRAPHICS_DRIVER = /usr/lib/x86_64-linux-gnu/libGL.so

2) Preload for the desired octave executable,

  LD_PRELOAD=GENERIC_GRAPHICS_DRIVER octave-cli


> But I'm currently lost with autotools/libtool and would need some tips
> how to create a slim liboctave (+libinterp?)

Rather than build a whole new octave, maybe experiment with the ideas 
above to see if you can generate an off-screen plot without Nvidia.  If 
so, then how about writing a short bash-script that does pretty much the 
same as described above?  That is

mycomp $ ./octave-print some_hgsave_fig

runs a script that internally searches for a generic driver, preloads 
it, and does what you described.  In fact, if you got such a thing 
working, that script could be used in the Makefile command that 
generates the Octave manual rather than have the searching done internal 
to the Makefile.

Dan