Linux – How to rebuild glibc on Arch Linux

arch linuxglibc

It seems like MATLAB is royally screwed up on Linux, because it "dynamically loads some libs with static TLS", which doesn't mean anything to me other than I get bunches of errors.

The suggested work around is to rebuild glibc with a larger DTV_SURPLUS. This leaves me with two questions:

How do I rebuild glibc on Arch Linux to increase the DTV_SURPLUS? I looked at the PKGBUILD in the abs tree and didn't see DTV_SURPLUS anywhere, so I don't know where to make the change.
What value do I set DTV_SURPLUS to be? Presumably, setting it to
2^64 would both be overkill and a bad idea.

The issue with MATLAB can be seen with the following MWE in 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)

Where ones(10)*ones(10); loads the dynamically linked libiomp5.so BLAS library, which seems to not leave enough space for the dynamically linked libxul.so required for the HTML based documentation browser. Potentially I can work around this particular MWE by using a patched version of libiomp5.so, but the general problem still persists.

Best Answer

To recompile glibc with custom DTV_SURPLUS and override the existing version:

Copy /var/abs/core/glibc to another directory so you can write to it without being root, then cd to that directory.
Use makepkg -o to download and extract the source code without building it(because we will edit the source code before building).
Edit DTV_SURPLUS located in src/glibc-<version>/sysdeps/generic/ldsodefs.h. You may just change the number in the line containing DTV_SURPLUS.
Build it with makepkg -e.
Install the custom version with sudo pacman -U <package file>. This will override the official package previously installed.

If you don't want to override the existing version, you can use chroot, or maybe LD_PRELOAD will also work.

However, I'm unsure what should DTV_SURPLUS be.

Related Solutions

RHEL – How to Run New Software Without Updating GLIBC

You can definitely compile a new version of GLIBC and have it stored in a separate directory. The first thing you'll have to do is download the version of glibc that you want from http://ftp.gnu.org/gnu/glibc/.

Run the configure script and set the --prefix= to something like /home/you/mylibs.

After you've managed to install it into that directory, you'll have to set your LD_LIBRARY_PATH to the location of the new glibc.

You'll need to figure out any dependencies you may need to compile. You can create a shell script that sets the LD_* variables and the runs your program (which you'd have to do anyway), and run it repeatedly - download/recompiling missing libs along the way.

You could also use ldd to determine what shared libraries the program needs, then use ldd on each of the libraries to find out if they require glibc.

This can be a very time consuming process and is not for the impatient or faint of heart - traversing/recompiling your way through the possible dependencies required to make your application work may occasionally make you want to pull out your hair.

Update 1:

I downloaded glibc-2.4 and tried to compile it on CentOS 6. To get configure working properly I had to change the ac and ld version checks by changing:

2.1[3-9]*)

to:

2.*)

at lines 4045 and 4106 in the configure file itself. I set my *FLAGS environment variables like so:

LDFLAGS="-Wl,--sort-common -Wl,-zcombreloc -Wl,-znow" 
CFLAGS="-pipe -fomit-frame-pointer -g1 -O3 -frename-registers -fweb -ftracer -fmodulo-sched -fvariable-expansion-in-unroller -fgcse-sm"
CXXFLAGS="${CFLAGS}" 
CFLAGS="${CFLAGS} -freorder-blocks-and-partition" 
export LDFLAGS CFLAGS CXXFLAGS

and then executed ./configure --prefix=/home/tim/masochist. It configured properly... and it began building properly too... but then I started running into errors - mostly the compiler complaining about things being redefined.

At that point I gave up... Because it was becoming too time consuming. ;)

glibc Upgrade – How to Properly Upgrade glibc

Upgrading the standard library is risky, as some programs and libraries may depend on the current version.

My recommendation if you need to run newer programs is to install a full chrooted distribution. This requires more disk space, but is a lot simpler and less risky than trying to update libc. Debian provides a tool to facilitate installations in a chroot: debootstrap. See Installing two glibc alongside in debian/ubuntu (a very similar situation) for more explanations and How do I run 32-bit programs on a 64-bit Debian/Ubuntu? for a full how-to in a slightly different situation.

Best Answer

Related Solutions

RHEL – How to Run New Software Without Updating GLIBC

glibc Upgrade – How to Properly Upgrade glibc

Related Question