[Top][All Lists]

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

Re: linking a slim liboctave without OpenGL or Nvidia stuff

From: Daniel J Sebald
Subject: Re: linking a slim liboctave without OpenGL or Nvidia stuff
Date: Fri, 22 Dec 2017 04:30:22 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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


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,


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.


reply via email to

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