Geek Answers Handbook

What is the difference between / lib / i 386-linux-gnu / libc.so.6, / lib / x86_64-linux-gnu / libc.so.6 and / usr / lib / x86_64-linux-gnu / libc.so?

I installed Matlab on my Linux Mint 14 Nadia (uname -a shows: Linux Ideapad-Z570 3.5.0-17-generiC # 28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux), and when you call it from the command line, I get: "/lib64/libc.so not found".

I followed the help in mathworks by creating a link in / lib 64 as:

ln -s /lib/x86_64-linux-gnu/libc.so.6 .

This solved the problem.

Now, if I find this library, I get:

 locate "libc.so" /lib/i386-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc.so

I will compile with gcc on this computer, and I would like to have full 64-bit compilations. What exactly does having all of these libc.so libraries mean? which one will gnu compiler use? do i need to do something else with gcc to compile for 64 bit?

I would also like to optimize as much as I can for my new i7 core.

+6
source share
3 answers

/lib/i386-linux-gnu/libc.so.6

This is a 32-bit version of the library.

/lib/x86_64-linux-gnu/libc.so.6

This is a 64-bit version of the library.

Both are usually symbolic links to the actual library file, which will usually be named according to the glibc release number, for example libc-2.15.so

/usr/lib/x86_64-linux-gnu/libc.so

This is not a library, but a script linker file that references the aforementioned symbolic links.

Why do we need all this:

First, regardless of the version of libc installed, the linker will always look for libc.so , because the compiler driver will always go to the -lc option linker. The name libc remains unchanged and indicates the latest version of the library.

Symbols libc.so.6 are named after the name of the library, which more or less corresponds to the version of the ABI library. The executables associated with libc.so actually contain runtime dependencies on libc.so.6 .

If we imagine that someday a crude ABI-incompatible libc will be released, its soname can be called libc.so.7 , for example, and this version of coukld coexists with the old version of libc.so.6 , so the executable files related to otherwise, can coexist in the same system

And finally, the name libc-2.15.so refers to the libc release, when you install the new libc package, the name will change to libc-2.16.so . Provided that it is compatible with binary from the previous release, the link libc.so.6 will remain named this way and existing executables will continue to work.

+10
source

To find which one to use, you must first find the order that ld (linker) uses to search for libraries, for example:

 ld --verbose | grep SEARCH

For me, this gave me this result:

 SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64"); SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");

This means that on my computer, ld scans these directories to:

  • / Usr / x86_64-unknown-linux-wildebeest / lib64
  • / Usr / x86_64-unknown-linux-wildebeest / Library
  • / Usr / lib
  • / Usr / local / library

So, if libc was in / usr / x 86_64-unknown-linux-gnu / lib64, and libc was also in / usr / lib, it would use the version / usr / x 86_64-unknown-linux-gnu / lib64, because he was listed first.

+2
source

The symlink you created will not have any effect in GCC. The 32-bit version is used only when compiling using the -m32 GCC flag. GCC will not attempt to generate 32-bit binaries unless you specifically specify this (using this flag.)

0
source

More articles:


All Articles