[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parallel make hangs
From: |
Daniel J Sebald |
Subject: |
Re: parallel make hangs |
Date: |
Wed, 22 Nov 2017 11:40:17 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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
- parallel make hangs, Dmitri A. Sergatskov, 2017/11/21
- Re: parallel make hangs, Daniel J Sebald, 2017/11/22
- Re: parallel make hangs, Dmitri A. Sergatskov, 2017/11/22
- Re: parallel make hangs, John W. Eaton, 2017/11/22
- Re: parallel make hangs, Dmitri A. Sergatskov, 2017/11/22
- Re: parallel make hangs, John W. Eaton, 2017/11/22
- Re: parallel make hangs, Dmitri A. Sergatskov, 2017/11/22
- Re: parallel make hangs, Dmitri A. Sergatskov, 2017/11/22
Re: parallel make hangs, John W. Eaton, 2017/11/22
- Re: parallel make hangs,
Daniel J Sebald <=
Re: parallel make hangs, John W. Eaton, 2017/11/22