Различие между lib, lib32, lib64, libx32, и libexec

А-ч да, это - очень запутывающая часть, если Вы имели дело с Unixes в течение какого-либо отрезка времени. Существует стандарт, за которым большинство Unixes "пытается" следовать названный FHS - Стандарт Иерархии Файловой системы.

Учитывая я, прежде всего, использую основанные на Red Hat дистрибутивы, я являюсь самым знакомым с их взятием на FHS для Fedora, CentOS и дистрибутивов Linux RHEL. Но я использовал основанные на Debian & BSD дистрибутивы также, и они не все это отличающееся с точки зрения того, где вещи сохранены, мудрая файловая система.

Теперь к Вашим вопросам. Я смотрел бы на документ FHS, который свободно управляет этими структурами каталогов. В целом:

Каталог - /lib

Содержит существенные общие библиотеки и модули ядра.

Цель: / каталог lib содержит те добавленные изображения библиотеки, должен был загрузить систему и выполнить команды в корневой файловой системе, т.е. двоичными файлами в / мусорном ведре и/sbin.

Note1: Общие библиотеки, которые только необходимы для двоичных файлов в/usr (таких как любые двоичные файлы X Window) не должны быть в / lib. Только общие библиотеки потребовали для выполнения двоичных файлов в / мусорном ведре, и/sbin может быть здесь.

Note2: Учитывая основную цель / lib должен содержать библиотеки для инструментов, развернутых на каталогах,/bin и/sbin, библиотеки в / lib могут быть или 32-разрядными или 64-разрядными.

Например (Fedora 14 64-разрядная система)

$ uname -a
Linux grinchy 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Вот выборка файлов от моего / lib

./libpam.so.0.82.2:             ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./libplc4.so:                   ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./libidn.so.11.6.1:             ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./upstart/telinit:              ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/runlevel:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/shutdown:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./upstart/reboot:               ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
./libdb-4.8.so:                 ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
./firmware/mixart/miXart8.elf:  ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
./libtinfo.so.5.7:              ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

Каталог - /lib<qual>

Альтернативный формат существенные общие библиотеки (дополнительно). Они были бы каталогами/lib32,/lib64 и т.д.

Цель: может быть один или несколько вариантов / каталога lib в системах, которые поддерживают больше чем один двоичный формат, требующий отдельных библиотек. Это является наиболее часто используемым для 64-разрядной или 32-разрядной поддержки в системах, которые поддерживают несколько двоичных форматов, но требуют библиотек того же имени.

Примечание: В этом случае/lib32 и/lib64 мог бы быть каталогами библиотеки и / lib символьная ссылка на одного из них.

Каталог - /usr/lib

Библиотеки для программирования и пакетов.

Цель:/usr/lib включает объектные файлы, библиотеки и внутренние двоичные файлы, которые не предназначаются, чтобы быть выполненными непосредственно пользователями или сценариями оболочки.

Note1: Разные архитектурно-независимые специализированные статические файлы и подкаталоги должны быть помещены в/usr/share.

Приложения могут использовать единственный подкаталог под/usr/lib. Если приложение использует подкаталог, все архитектурно-зависимые данные, исключительно используемые приложением, должны быть помещены в том подкаталоге.

Note2: Например, perl5 подкаталог для Perl 5 модулей и библиотеки.

Каталог - /usr/lib<qual>

Альтернативные библиотеки формата (дополнительно).

Цель: /usr/lib<qual> выполняет ту же роль/usr/lib для альтернативного двоичного формата, за исключением того, что символьные ссылки /usr/lib<qual>/sendmail и /usr/lib<qual>/X11 не требуются.

Примечание: Случай, где/usr/lib и /usr/lib<qual> то же (каждый - символьная ссылка на другой), эти файлы и подкаталоги на приложение будут существовать.

TLDR;

В целом:

Если существуют библиотеки, которые требуются исполняемым файлом или в / мусорном ведре или в/sbin каталогах, те библиотеки должны входить в / lib* каталоги.

Если существуют библиотеки для программ использования и пакетов, они входят в/usr/lib /*. Если существуют исполняемые файлы, которые необходимы конкретной библиотеке, но эти исполняемые файлы не, предполагают, чтобы быть названным пользователями непосредственно или корнем, они входят в/usr/libexec.