Como reconstruir o glibc no Arch Linux?

Parece que o MATLAB está totalmente ferrado no Linux, porque "carrega dinamicamente algumas bibliotecas com TLS estático" , o que não significa nada para mim, exceto que recebo muitos erros.

A solução sugerida é reconstruir glibccom um tamanho maior DTV_SURPLUS. Isso me deixa com duas perguntas:

Como faço para reconstruir glibcno Arch Linux para aumentar o DTV_SURPLUS? Olhei para o PKGBUILD na árvore do abs e não vi em DTV_SURPLUSlugar nenhum, então não sei onde fazer a alteração.
Que valor eu defino DTV_SURPLUSpara ser? Presumivelmente, defini-lo como 2^64seria um exagero e uma má ideia.

O problema com o MATLAB pode ser visto com o seguinte MWE no R2014a:

>> ones(10)*ones(10);
>> doc('help');
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)
Exception in thread "XPCOMMessageLoop" java.lang.UnsatisfiedLinkError: /opt/matlab/sys/jxbrowser/glnxa64/xulrunner/xulrunner-linux-64/libxul.so: dlopen: cannot load any more object with static TLS
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.c(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.impl.linux.LinuxMozillaToolkit.a(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.MozillaToolkit.initialize(Unknown Source)
    at com.teamdev.jxbrowser.gecko.xpcom.AppShellXPCOMThread$b.run(Unknown Source)

Onde ones(10)*ones(10);carrega a libiomp5.sobiblioteca BLAS vinculada dinamicamente , que parece não deixar espaço suficiente para o vínculo dinâmico libxul.sonecessário para o navegador de documentação baseado em HTML. Potencialmente, posso solucionar esse MWE específico usando uma versão corrigida do libiomp5.so, mas o problema geral ainda persiste.

arch-linux glibc

— StrongBad
fonte

Provavelmente, seria melhor verificar se há uma distribuição que já tenha o glibc compilado com um DTV_SURPLUS mais alto - talvez testando em uma VM.

— 8298 goldilocks

@goldilocks um chroot seria suficiente ou preciso de uma VM completa?

— StrongBad

Encontrei isso: stackoverflow.com/questions/19268293/… e este: mathworks.com/matlabcentral/answers/… . Uma pesquisa no Google após "não é possível carregar mais nenhum objeto com TLS estático" é obrigada a fornecer mais idéias.

— schaiba

Vinculei à pergunta SO na minha pergunta e foi aí que a idéia de reconstrução glibcfoi sugerida.

— StrongBad

O kernel não é um problema, portanto você pode usar o chroot.

— 8289 goldilocks

Para recompilar o glibc com custom DTV_SURPLUSe substituir a versão existente:

Copie /var/abs/core/glibcpara outro diretório para poder gravá-lo sem ser root e depois cdpara esse diretório.
Use makepkg -opara baixar e extrair o código fonte sem compilá-lo (porque editaremos o código fonte antes da compilação).
Editar DTV_SURPLUSlocalizado em src/glibc-<version>/sysdeps/generic/ldsodefs.h. Você pode apenas alterar o número na linha que contém DTV_SURPLUS.
Construa com ele makepkg -e.
Instale a versão personalizada com sudo pacman -U <package file>. Isso substituirá o pacote oficial instalado anteriormente.

Se você não deseja substituir a versão existente, pode usar o chroot, ou talvez o LD_PRELOAD também funcione.

No entanto, não tenho certeza do que deveria DTV_SURPLUSser.

— user4098326
fonte