liblib32lib64libx32

lib64一样，软件使用64位的指令和64位的指针

lib32，软件使用32位的指令和32位的指针，在64位编译器下使用 –m32 编译输出

libx32，软件使用64位的指令但是使用32位的指针长度，编译时使用 –mx32 指定编译输出

lib这个目录一般和lib32的内容一致，但也可能存放了一些lib64的库

libx32这种模式内核开发者正在讨论是否要删除掉，详见如下链接

https://www.phoronix.com/news/Linux-Potentially-Drops-x32

还有一个关于这块内容的介绍

https://cds.cern.ch/record/1528222/files/LHCb-TALK-2013-060.pdf

程序在加载时是如何执行的，这个和动态连接器（ld-linux.so或者ld.so）有关系，它的作用是定位应用程序使用的动态库并将其加载到内存中。

ELF标准说当文件中存在一个名为INTERP的特殊段时，这个段制定了解释器的路径，当应用程序被加载时，操作系统将控制权传递给ld-linux.so，一个elf文件包含了解释器，我们可以通过readelf -l命令查看INTERP

如下面的例子，在64位ubuntu下，我们写一个测试的test.c，并使用-m32编译出test.x86，使用-mx32编译出test.x32以及test.x64，使用file命令查看如下

wlan@linux:/tmp$ file *

test.c:      C source, ASCII text

test.x32:    ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, BuildID[sha1]=bcd7f0870afad7a11f4e941598ae1c2313f6d745, not stripped

test.x64:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=346faf451d9e850ec354744082c6828b859b1b01, not stripped

test.x86:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b5d41731973d212d674fb5106126d50faf849177, not stripped

再使用readelf -l命令如下

#readelf -l test.x86，输入如下

我们看到x86的解释器路径并且地址为32位

#readelf -l test.x64 输出如下

我们看到x64的解释器路径并且地址为64位

#readelf -l test.x32 输出如下

我们看到x32的解释器路径但是地址为32位