Xojo2015r3 GLIBC_2.14

Afternoon everyone. I was very excited to get the new 64-bit version of Xojo and quickly compiled a 64-bit hello world console app on my mac with the target set to be 64bit architecture linux. However all our big linux servers are running CentOS 6.x and none of them as a consequence can launch the app. CentOS 6.x uses GLIBC_2.12 and ldd shows that GLIBC_2.14 is needed.

I’m not 100% sure on this but my general thinking is that upgrading to GLIBC_2.14 would require essentially replacing CentOS 6 with 7 which is probably not going to happen. Are there any simple work arounds for this? Would the loader accept if I just put the later libc.so.6 into a local directory and changed LD_LIBRARY_PATH to point at it? I seem to have waited a decade for a 64bit version of Xojo and now I can’t use it … which is a bit disappointing.

$ ldd test
./test: /lib64/libc.so.6: version `GLIBC_2.14’ not found (required by /storage/aplatts/data/testx64/./test Libs/XojoConsoleFramework64.so)
linux-vdso.so.1 => (0x00007fff305d9000)
XojoConsoleFramework64.so => /storage/aplatts/data/testx64/./test Libs/XojoConsoleFramework64.so (0x00007ff6689d3000)
libc.so.6 => /lib64/libc.so.6 (0x000000373aa00000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x000000373d600000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x000000373c200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000373b200000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000373b600000)
libm.so.6 => /lib64/libm.so.6 (0x000000373ae00000)
libc++.so.1 => /storage/aplatts/data/testx64/./test Libs/libc++.so.1 (0x00007ff66860b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003745200000)
/lib64/ld-linux-x86-64.so.2 (0x000000373a600000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x000000373ce00000)
librt.so.1 => /lib64/librt.so.1 (0x000000373ba00000)

GLIBC 2.14+ is required for 64-bit apps. Almost every distribution has had that for years, with RHEL/CentOS being the hold outs until the 7 series.

Thanks Travis - unfortunately CentOS 6.x remains perhaps one of the more common distros in use in our area of science and that’s not something the people at the user level like me are going to be able to change in the next few years.

We worked very hard to maintain the same compatibility in 32-bit, but our new LLVM based toolchain for 64-bit requires the newer version of Glibc on Linux.

Thanks Travis, I get that this isn’t something that you guys want to change at your end. But I’m still hunting for a solution … could I use LD_PRELOAD to perhaps associate the Xojo executable with some specific library?

It’s not out of the realm of possibility, but not something we can support since the distribution itself does not support it.

OK. It’s working, thanks. Phew!

I grabbed the latest GLIBC libraries for CentOS & extracted them to a user-level directory:
rpm2cpio glibc-2.17-78.el7.x86_64.rpm | cpio -idmv

Tweaked the interpreter location from the hard coded path in the Xojo app to the path in the package downloaded
./patchelf --set-interpreter /storage/aplatts/data/testx64/lib64/ld-linux-x86-64.so.2 …/…/test

Finally set the LD_LIBRARY_PATH to be the newly downloaded libs:
export LD_LIBRARY_PATH=/data/aplatts/data/testx64/lib64/

and … the 64-bit arch test app runs:

[aplatts@grandiflora testx64]$ ./test

Hello everyone. I have the same problem, but with a desktop app. The solution to switch the glibc is a very bad idea, please read this


You should remove the support entry for CentOS 6 on your page.


Hi Ingo - I think the CentOS forum discussion considers replacing the central GLIBC which is indeed not a good idea. The discussion above mostly considered the separate case of installing a secondary version of GLIBC at the user level and how to make Xojo apps use these libraries, which turned out to be not so difficult although it wouldn’t be something to do in a commercial distribution perhaps? The system page dos note that CentOS 7 is needed for x86-64 apps (CentOS 6.0 or later (7.0 or later for x86-64)).

Hi Adrian

I tried your solution with a desktop program and get the following error messages. I think the same problem with the glibc is concerning web programs. Did you tried that already?.

( CentOS 6 - Support - Requirements ) - Yes you are right, that was my mistake.

(process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init()
(process:4913): GLib-CRITICAL **: g_once_init_leave: assertion initialization_value != 0' failed (process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init() (process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init() (process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init() (process:4913): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion G_TYPE_IS_INSTANTIATABLE (instance_type)’ failed
(process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init()
(process:4913): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion G_TYPE_IS_INTERFACE (interface_type)' failed (process:4913): GLib-CRITICAL **: g_once_init_leave: assertion initialization_value != 0’ failed
(process:4913): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)’ failed
(process:4913): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init()

@Ingo - I only have the console license so can’t test that scenario so well. Sorry for that, perhaps others can help (although it seems similar to: https://bbs.archlinux.org/viewtopic.php?id=162320)