[Nix-dev] OpenGL and Nix

[stewart mackenzie]

Dear nixers,

I need to understand something, namely how Nix handles OpenGL, cause
something is nasty, something feels wrong, something is off and I
don't know what it is.

Problem:
Fractalide runs out of Static TLS variables to allocate when
dynamically linking mesa_glu/lib/libGL.so.
the thread panics and blows up.

exemplified with this error:

[stewart at rivergod:~/dev/fractalide/fractalide]$ ./result/bin/development_test
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err`
value: "SDL error: Failed loading libGL.so.1: dlopen: cannot load any
more object with static TLS"', src/libcore/result.rs:746
stack backtrace:
   1:     0x7f0e77aed190 -
sys::backtrace::tracing::imp::write::hc6c5b88e91cce321Nyu
Segmentation fault

debugging route:

I run `objdump -r /tmp/nix-build-mesa.xxxx/src/glx/.libs/*.o | grep TPOFF`
and `objdump -r /tmp/nix-build-mesa.xxxx/src/glx/.libs/*.o | grep TLS`
for every *.o file.

this shows to me that indeed my

tls-mesa_noglu = stdenv.lib.overrideDerivation mesa_noglu (oldAttrs : {
postPatch = oldAttrs.postPatch + ''
    substituteInPlace src/egl/main/eglcurrent.c --replace initial-exec
global-dynamic
    substituteInPlace src/glx/glxclient.h --replace initial-exec global-dynamic
    substituteInPlace src/glx/glxcurrent.c --replace initial-exec global-dynamic
    substituteInPlace src/mapi/glapi/glapi.h --replace initial-exec
global-dynamic
    substituteInPlace src/mapi/u_current.c --replace initial-exec global-dynamic
    substituteInPlace src/mapi/u_current.h --replace initial-exec global-dynamic
    substituteInPlace src/mesa/drivers/dri/common/dri_test.c --replace
initial-exec global-dynamic
    echo $out # I use this to determine the final out dir of mesa_noglu
    ''; });

Is correct!

some sample output:

...
[root at rivergod:/tmp/nix-build-mesa-noglu-11.1.1.drv-1/mesa-11.1.1/src/glx/.libs]#
objdump -r glxcurrent.o | grep TPOFF
000000000000648a R_X86_64_DTPOFF32  __glX_tls_Context
0000000000000060 R_X86_64_DTPOFF32  __glX_tls_Context
000000000000008c R_X86_64_DTPOFF32  __glX_tls_Context

[root at rivergod:/tmp/nix-build-mesa-noglu-11.1.1.drv-1/mesa-11.1.1/src/glx/.libs]#
objdump -r glxcurrent.o | grep TLS
0000000000000013 R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004
0000000000000038 R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004
0000000000000064 R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004
0000000000000094 R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004
00000000000000ce R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004
0000000000000177 R_X86_64_TLSGD    __glX_tls_Context-0x0000000000000004

etc etc for every single *.o file in the .libs folder. Notice the D?
Well that means Dynamic.

This means that I am correctly overriding `mesa_glu` with
`global-dynamic` tls-model and that *none* of my files are compiled
using static tls which would automatically default the artifact
libGL.so to be STATIC_TLS.

when I run on the final build product :
[stewart at rivergod:~/dev/fractalide/fractalide]$ readelf --dynamic
/nix/store/nkva88kqcjddgl2gpkjzzz4rvxkprr40-mesa-noglu-11.1.1/lib/libGL.so
| grep STATIC_TLS
 0x000000000000001e (FLAGS)              SYMBOLIC STATIC_TLS

STATIC_TLS shouldn't be there!

My question to you: Is somehow libGL.so not pure... is it somehow
injected into this system some way some how? It should be purely
dynamic and absolutely not static. WTF is going on here?

/sjm