Error While Using a Newer Version of Glibc

Error while using a newer version of glibc

export LD_LIBRARY_PATH=/home/MYNAME/dependency/glibc-2.16/lib

This answer explains why LD_LIBRARY_PATH doesn't work, and what you should do instead.

I read your post and tried ...

python: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument

The error usually means that you have a mismatch between ld-linux and libc.so.6. They must match.

If you are using direct loader invocation via /home/MYNAME/.../ld-2.16.so, you must also arrange for /home/MYNAME/.../libc.so.6 to be loaded.

You can do that by passing --library-path ... to ld-2.16.so, or setting LD_LIBRARY_PATH appropriately.

Your command with ld-2.16 --library-path ... ls is almost correct. The thing you are missing is that ld-2.16 will not search your PATH. You need to give it full pathname: ld-2.16 --library-path ... /bin/ls.

Problems discovering glibc version in C++

The fundamental problem is that the glibc version is a string and not a decimal number. So for a "proper" solution you need to parse it manually and implement your own logic to decide which version is bigger or smaller.

However, as a quick and dirty hack, try inserting the line

setlocale(LC_NUMERIC, "C");

before the strtod call. That will set the numeric locale back to the default C locale where the decimal separator is .. If you're doing something that needs correct locales later in the program you need to set it back again. Depending on how your program initialized locales earlier, something like

setlocale(LC_NUMERIC, "");

should reset it back to what the environment says the locale should be.

Building and using a newer GLIBC on CentOS 7

Try ./testrun.sh /bin/ls.

That said, you will really be better off building the Python package for your system, instead of trying to make non-system GLIBC, as Danila Vershinin suggested.

Update:

libselinux.so.1: ...: No such file or directory

The testrun.sh for the new GLIBC does not look in system directories (e.g. /usr/lib64). You need to append system directories to the --library-path it uses. E.g. change

--library-path "${builddir}":"${builddir}"/math:"${builddir}"/elf:"${builddir}"/dlfcn:"${builddir}"/nss:"${builddir}"/nis:"${builddir}"/rt:"${builddir}"/resolv:"${builddir}"/mathvec:"${builddir}"/support:"${builddir}"/crypt:"${builddir}"/nptl

to:

--library-path "${builddir}":"${builddir}"/math:"${builddir}"/elf:"${builddir}"/dlfcn:"${builddir}"/nss:"${builddir}"/nis:"${builddir}"/rt:"${builddir}"/resolv:"${builddir}"/mathvec:"${builddir}"/support:"${builddir}"/crypt:"${builddir}"/nptl:/usr/lib64:/lib64

(or something like that).

valgrind doesn't accept newest version of glibc

How can I deal with this?

One of two ways:

1. Use your distribution and download the package they've already built for you, or
2. Figure out the problem (which is that configure has not been regenerated after 2.15 was added to configure.in) and fix it.

do I have to downgrade glibc?

That will likely render your system un-bootable (because most other binaries depend on 2.15).

---

Related Topics