Re: parallel make hangs

[Daniel J Sebald]

On 11/22/2017 09:34 AM, John W. Eaton wrote:
> On 11/21/2017 10:06 PM, Daniel J Sebald wrote:
>
> > Those happen sometimes.  Here the make process hangs on voronoi.eps 
> > (regardless of parallel build or not), but I think that is a 
> > long-standing bug with osmesa and nVidia drivers.
>
> I'm surprised that you have any success mixing the nvidia libGL with 
> OSMesa.  I don't think the layout of the GL context used the the nvidia 
> library is compatible with the one used by Mesa.  As far as I know, the 
> only way to make that work properly is to use the Mesa libGL and force 
> software rendering.  What happens if you do that, by setting 
> LD_PRELOAD=/path/to/your/mesa/libGL.so and LIBGL_ALWAYS_SOFTWARE=1 in 
> the build environment?  Does it hang then?  Are both actually needed for 
> building?  Since that is only doing off-screen rendering, then the 
> LIBGL_ALWAYS_SOFTWARE might not be needed.

I would guess that you are correct on the LIBGL_ALWAYS_SOFTWARE=1 
switch.  Rather than rebuild for that, let me go back to the default 
configure and try preloading libGL.so.

I don't think I am having partial success.  Running in the -j4 mode 
makes it appear that some things have succeeded when in fact they are 
all four still active, e.g.:

  GEN      doc/interpreter/voronoi.txt
  GEN      doc/interpreter/triplot.txt
  GEN      doc/interpreter/griddata.txt
  GEN      doc/interpreter/convhull.txt
  GEN      doc/interpreter/delaunay.txt
  GEN      doc/interpreter/inpolygon.txt
  GEN      doc/interpreter/voronoi.eps
  GEN      doc/interpreter/triplot.eps
  GEN      doc/interpreter/griddata.eps
  GEN      doc/interpreter/convhull.eps
^C^C^Cfatal: caught signal fatal: caught signal fatal: caught signal 
Interruptfatal: caught signal Interrupt -- stopping myself...Interrupt 
-- stopping myself...Interrupt
 -- stopping myself... -- stopping myself...

voronoi.eps (the very first EPS figure generated) is failing.

OK, well I didn't follow your description precisely on locating the 
OSMesa libGL.so and instead chose

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

which I assume is the generic linux driver (as opposed to graphics-card 
specific which I think is /usr/lib/nvidia-340/libGL.so), but that 
appears to work.

Well, that's at least getting me a little further in a convenient way 
(i.e., don't have to build with the

configure --without-osmesa --no-recursion

).

And actually that may be a partial solution, at least for people 
building with nVidia drivers, in the sense that if the build process can 
recognize that there is a libGL.so driver in the conventional location, 
i.e., directory

/usr/lib/x86_64-linux-gnu

or some standard make-tools LDPATH variable, force the documentation 
steps to pre-load *that* driver instead of any possible graphics-card 
specific driver that it would use otherwise.  What does it matter which 
driver is used if there is going to be no screen graphics?

Another alternative is to maybe explore some settings in the following 
list of OSMesa build options (OSMesa is built particular to Octave's 
make?  I'm not sure, really.  I looked at this some time ago...oh wait, 
I'm actually remembering now having debugged swrast at some point so the 
following options would be an extensive rebuild):

https://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#Mesa_for_your_CPU_.28i.e._without_graphics_hardware.2C_and_OSMesa.29

Anyway, how about the search for the standard libGL.so and pre-load when 
building documentation?

Dan