Согласование архитектур в Linux?

Question

[WSGlebKavash]

В Windows 16-битные библиотеки хранятся в 'C:\Windows\System', 32-битные библиотеки в 'C:\Windows\SysWOW64', 64-битные библиотеки в 'C:\Windows\System32'. 64-битные программы хранятся в 'C:\Program Files', а 32-битные программы - в 'C:\Program Files (x86)'.
В Linux все бинарники хранятся в /usr/bin/, а конфиги - в /etc. Но при этом Linux поддерживает кучу архитектур.
Как происходит согласование 32-битных и 64-битных библиотек в Linux и почему нет конфликтов?

Comments

[hint000]

Кстати, поддержка легаси x86 (32 bit) сокращается. Например, Убунта уже несколько лет не выпускает дистрибутивы под x86.

[WSGlebKavash]

hint000,

Убунта уже несколько лет не выпускает дистрибутивы под x86.

Последняя 32-битная Ubuntu - это Ubuntu 18.04 LTS. Начиная с 19.03 32-битных сборок нет. Но 32-битные программы можно запускать в 64-битной ОС.
Но тут Microsoft перестаёт собирать 32-битные сборки для Windows 11, а это значит, что 32-битный Linux потихонечку умрёт.

Answer 1

[AVKor]

В Linux все бинарники хранятся в /usr/bin/

Нет.

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

Для Дебьяна информацию можно найти здесь и тут. По другим дистрибутивам, полагаю, тоже есть информация на их сайтах.

Comments

[WSGlebKavash]

AVKor,

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

Большое спасибо за объяснение. А в Windows это работает как костыль. Запросы файловой системы для 32-битных x86 приложений перенаправляются:

C:\Windows\System32 --> C:\Windows\SysWOW64
C:\Program Files --> C:\Program Files (x86)
C:\Windows\sysnative --> C:\Windows\System32

Запросы файловой системы для 32-битных ARM приложений перенаправляются:

C:\Windows\System32 --> C:\Windows\SysARM32
C:\Windows\sysnative --> C:\Windows\System32

При этом систему можно вежливо попросить не делать такое перенаправление.

Answer 2

[shurshur]

Да, конечно, Linux поддерживает кучу архитектур, но код для архитектуры mipsel нельзя запустить на armhf. Поэтому проблемы именно "кучи" нет - никто не использует программы, которые всё равно не запустятся.

Есть проблема только с поддержкой совместимх архитектур x86 и x86_64. В результате в основном пришли к тому, что есть /lib|/usr/lib|/usr/local/lib и /lib64|/usr/lib64|/usr/local/lib64 или такие же с lib32|lib или даже ортогональный им lib32|lib64 для библиотек, а для бинарников такой проблемы нет, потому что какая разница, будет ли единственный файл /usr/bin/program 32-битной или 64-битной приложенькой? В крайнем случае в имя программы можно добавить 32 (или даже -x86|-x86_64) на конце.

С учётом того, что в LINUX можно положить библиотеки в /foo/bar, а исполняемые файлы в /lorem/ipsum и разрулить это с помощью PATH и ld.so.conf, можно сделать вообще как душе угодно. Не забываем также, что в грамотно организованной и правильно администрируемой системой всё по возможности ставится из пакетов. Поэтому каждый файл учтён, ничто не будет перезаписано при установке/обновлении.

Comments

[WSGlebKavash]

shurshur,

С учётом того, что в LINUX можно положить библиотеки в /foo/bar, а исполняемые файлы в /lorem/ipsum

Так делает Microsoft SQL Server. Они придерживаются Виндовс-вэй, и кладут всё в одну папку. Но это проприетарное ПО, им можно.

но код для архитектуры mipsel нельзя запустить на armhf.

В Windows 10 можно на ARM64 запустить x86 программы. А в Windows 11 можно на ARM64 запустить x86 и x86_64 программы. На компьютерах Apple с процессором M1 такая фишка тоже работает и вроде даже лучше, чем у Microsoft.

Большое спасибо за ответ.

[shurshur]

WSGlebKavash, так делает не только проприетарный софт. Некоторые приложения предпочитают устанавливаться в /opt. Например, у меня RocketChat туда поставился. Это не так плохо для некоторых категорий софта (особенно того, который очень большой и сложный и слабо зависит от общесистемных компонентов).

На других архитектурах фактически приложение запускается в эмуляторе. Это адовый костыль. В Linux тоже можно приложения через wine запускать, но родной для Linux софт просто компилируют сразу в нужную архитектуру и в идеале кладут в пакетную базу.