I met a problem when trying to install a R package called "GenomicFeatures",

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '$HOME/.R325/lib64/R/library/RCurl/libs/RCurl.so':
  /lib64/libc.so.6: version `GLIBC_2.7' not found 

I checked the, the root does not have such a library.


I noticed the kind suggestion made by eyoung100, which might solve my issue. My knowledge about unix/linux is still in its infancy, it seems to me he suggested a mini version of the whole root, and install the RPM package in the "newroot".

it seemed to me he suggested to install the whole system, is that necessary?

Any suggestion? if any information is needed to solve the issue, please kindly let me know.

  • 1
    I am sorry that I couldn't provide an easy solution, but what you now try to do, is analoge in the Windows world as if you would want to use an application running on at least Win7, on a WinXP. In the Linux world, it is still possible (also in the Win world), but none of the solutions are easy.
    – peterh
    Feb 18 '17 at 11:31
  • What distribution are you running? What version? Feb 18 '17 at 23:49
  • @Gilles, LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: CentOS Description: CentOS release 5.10 (Final) Release: 5.10 Codename: Final
    – Jun
    Feb 19 '17 at 1:34
  • 1
    This thread on Server Fault suggests that libc 2.7 on CentOS 5 is a lost cause. You should try to recompile the package from source, or upgrade to CentOS 6. Feb 19 '17 at 2:59

Another idea (this is why I post it as a new answer):

Some distros load the libraries from different places. For example, on Debians, the libc isn't in /usr/lib64, but in /lib/x86_64-linux-gnu . It is not a compatibility problem, because the apps should load the system libraries from the directories configured by the system for them. This app breaks this, it tries to load the libc from a hardwired location, thus it is the fault of the developers of this app.

Check where is your libc.so.6 (most easily you can see that by an

ldd /bin/bash

command), and simply create a soft link to that directory in your /usr/lib64 (the command: ln -sv /my/libc/directory /usr/lib64 ).

  • Thanks for your kind suggestion: here is my (system) libc.so.6:$ ldd /bin/bash linux-vdso.so.1 => (0x00007fffb3dfd000) libtermcap.so.2 => /lib64/libtermcap.so.2 (0x0000003cb0c00000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003cae000000) libc.so.6 => /lib64/libc.so.6 (0x0000003cad800000) /lib64/ld-linux-x86-64.so.2 (0x0000003cad400000)
    – Jun
    Feb 18 '17 at 11:47
  • you mean install a glib package [like here] (ftp.gnu.org/gnu/libc) in "/mydirectory/libc/directory", and run the command "ln -sv /my/libc/directory /usr/lib64"?
    – Jun
    Feb 18 '17 at 11:51
  • my OS is :cat /etc/*-release CentOS release 5.10 (Final), you mention Debians, do your think the same solution also apply to my OS?
    – Jun
    Feb 18 '17 at 11:54
  • @Jun Download and extract a binary (precompiled) glibc distribution, ideally a glibc2.7 one. Extract it into a specific directory in your home (for example, /home/jun/glibc4r). Then start the R from the command line, but prefixing with LD_LIBRARY_PATH=/home/jun/glibc4r . Here you give the path which contains the libc.so.6 from your downloaded glibc. It will result that this command, and only this command, will first try to load libraries from your directory, and only then will it check for the system libs.
    – peterh
    Feb 18 '17 at 12:26
  • I could not find a binary glibc distribution. So I decided to install one from source, but met some issues. I will post a new question about it. A working issue now is when I tried to do configure, I had error complaining my gcc version is too old, but "gcc (GCC) 6.1.0" my gcc far exceed the required indicated in the "INSTALL" file...
    – Jun
    Feb 18 '17 at 13:18

This package requires at least version 2.7 of the glibc, which is still quite old, but your distro seems much older.

If a chroot solution and also a system upgrade are unviable, there are 2 other ways:

  1. You can upgrade only the glibc on your system. They are strongly backward compatible, so it probably won't break anything, but you still risk the ruining of your system into a state where you won't be able to fix it.

  2. You can extract the glibc files from a newer glibc package into a local directory, and run only that process with that specific directory. You can do this with the LD_LIBRARY_PATH environment variable. Knowing that this is an R module, which is called not directly by you, but by the R, you will probably have to implement some trivial shellscript wrapper for the task.

  • Here is a question with the same problem as yours, check the links in it.
    – peterh
    Feb 18 '17 at 12:33
  • sorry that I just noticed you suggestion here, checking...
    – Jun
    Feb 18 '17 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.