Ese es el error no 961964 de MATLAB conocido desde R2012b (8.0). MATLAB carga dinámicamente algunas bibliotecas con TLS estático (almacenamiento local de subprocesos, por ejemplo, consulte el indicador del compilador gcc -ftls-model). Cargando demasiadas bibliotecas de este tipo => no queda espacio.
Hasta ahora, la única solución de mathwork es cargar las bibliotecas importantes (!) Primero usándolas antes (sugieren poner "unos (10) * unos (10);" en startup.m). Será mejor que no comente sobre esta "estrategia de solución".
Desde R2013b (8.2.0.701) con Linux x86_64, mi experiencia es: ¡No use "doc" (el sistema de ayuda gráfica)! Creo que esta doc-utility (libxul, etc.) está usando mucha memoria TLS estática.
Aquí hay una actualización (2013/12/31)
Todas las siguientes pruebas se realizaron con Fedora 20 (con glibc-2.18-11.fc20) y Matlab 8.3.0.73043 (versión preliminar de R2014a).
Para obtener más información sobre TLS, consulte Ulrich Drepper, ELF handling For Thread-Local Storage, versión 0.21, 2013, actualmente disponible en Akkadia y Redhat .
¿Qué pasa exactamente?
MATLAB dinámicamente (con dlopen) carga varias bibliotecas que necesitan la inicialización de tls. Todas esas bibliotecas necesitan una ranura en el dtv (vector de hilo dinámico). Debido a que MATLAB carga varias de estas librerías dinámicamente en tiempo de ejecución en tiempo de compilación / enlace, el enlazador (en mathworks) no tuvo la oportunidad de contar las ranuras necesarias (esa es la parte importante). Ahora es tarea del cargador dinámico de bibliotecas manejar un caso de este tipo en tiempo de ejecución. Pero esto no es fácil. Para citar dl-open.c:
Para TLS estático tenemos que asignar la memoria aquí y ahora. Esto incluye la asignación de memoria en la DTV. Pero no podemos cambiar ninguna DTV que no sea la nuestra. Entonces, si no podemos garantizar que haya espacio en la DTV, ni siquiera lo probamos y fallamos la carga.
Hay una constante de tiempo de compilación (llamada DTV_SURPLUS, ver glibc-source / sysdeps / generic / ldsodefs.h) en el cargador dinámico de bibliotecas de glibc para reservar un número de ranuras adicionales para tal desorden (cargando dinámicamente bibliotecas con TLS estático en un subproceso múltiple programa). En la versión glibc de Fedora 20, este valor es 14.
Aquí están las primeras bibliotecas (ejecutando MATLAB) que necesitaban ranuras dtv en mi caso:
matlabroot/bin/glnxa64/libut.so
/lib64/libstdc++.so.6
/lib64/libpthread.so.0
matlabroot/bin/glnxa64/libunwind.so.8
/lib64/libuuid.so.1
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/server/libjvm.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libfontmanager.so
matlabroot/sys/java/jre/glnxa64/jre/lib/amd64/libt2k.so
matlabroot/bin/glnxa64/mkl.so
matlabroot/sys/os/glnxa64/libiomp5.so
/lib64/libasound.so.2
matlabroot/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so
/lib64/libselinux.so.1
/lib64/libpixman-1.so.0
/lib64/libEGL.so.1
/lib64/libGL.so.1
/lib64/libglapi.so.0
Sí, más de 14 => demasiados => no queda espacio en el dtv. Eso es lo que el mensaje de error intenta decirnos y especialmente Mathworks.
Para el registro: para no violar la licencia de MATLAB, no depuré, descompillé ni desensamblé ninguna parte de los binarios enviados con MATLAB. Solo depuré los binarios glibc abiertos y gratuitos de Fedora 20 que MATLAB estaba usando para cargar dinámicamente las bibliotecas.
¿Qué se puede hacer para solucionar este problema?
Hay 3 opciones:
(a) Reconstruya MATLAB y no cargue dinámicamente esas bibliotecas (con el modelo initial-exec tls) en lugar de vincularlas (¡entonces el vinculador puede contar las ranuras requeridas!)
(b) Reconstruya esas librerías y asegúrese de que NO estén usando el modelo initial-exec tls.
(c) Reconstruir glibc y aumentar DTV_SURPLUS en glibc / sysdeps / generic / ldsodefs.h
Obviamente, las opciones (a) y (b) solo pueden realizarse con mathworks.
Para la opción (c) no se necesita ninguna fuente de MATLAB y, por lo tanto, se puede hacer sin mathworks.
¿Cuál es el estado en Mathworks?
Realmente intenté explicar esto al "Departamento de Soporte Técnico de MathWorks". Pero mi impresión es: no me entienden. Cerraron mi ticket de soporte y sugirieron una conversación telefónica (!) En enero de 2014 con un gerente de soporte técnico.
Haré todo lo posible para explicar esto, pero para ser honesto: no tengo mucha confianza.
Actualización (2014/01/10): Actualmente, Mathworks está probando la opción (b).
Actualización (19/03/2014): para el archivo libiomp5.so puede descargar una versión recién compilada (sin TLS estático) en mathworks, informe de error 961964 . ¿Y las otras librerías? No hay mejoría allí. Así que no se sorprenda de obtener "dlopen: no se pueden cargar más objetos con TLS estático" con "doc", por ejemplo, consulte el informe de error 1003952 .