LINUX.ORG.RU
Форум — General  

Multiarch. требуется разъяснение.

 ,


0

1

«Не было печали - апдейтов накачали». Собственно, стоял себе Debian 6, но стало скучно, и сделал апдейт до Debian 7. Ну и столкнулся с мультиарчем. Вроде, ничего сложного, но я запутался. Постараюсь изложить как я все это понял, а вы, пожалуйста, поправьте.

1)Итак, у нас имеется dpkg и apt с поддержкой мультиарча. Т.е. мы можем добавить «чужую»(foreign) архитектуру, и соответственно, устанавливать\скачивать пакеты этой архитектуры. Тут вроде все ясно.

2)Дабы не мешать мух с котлетами придумали систему префиксов(triplet): либы /lib32 - линк(бинд) /lib/i386-linux-gnu/ либы /lib64 - линк(бинд) /lib/x86_64-linux-gnu/ либы /usr/lib32 - линк(бинд) /usr/lib/i386-linux-gnu/ либы /usr/lib64 - линк(бинд) /usr/lib/x86_64-linux-gnu/

Т.е для приложения все осталось как было.

3)При установке пакета, dpkg сам кладет библиотеки в нужный префикс, в зависимости от архитектуры пакета.

4)Все бинарники находятся вперемешку в папках $PATH

Вроде на этом все, но, мне не очень понятно, каким образом система знает какой бинарник( они же теперь могут быть разноархитектурными ), каким ld (из какого префикса) «запускать», по сигнатуре? В общем, тут я немного поплыл, и очень сложно сформулировать вопросы, т.к. они возникают по ходу, но очень хочу понять.

Думаю, на этом не все, остально буду доспрашивать по мере. Спасибо за помощь.



Последнее исправление: cetjs2 (всего исправлений: 1)
← Directory junctions в Linux
swap при 16 ГБ ОЗУ. →

нет там никаких линк бинд, все каталоги как каталоги.


krab@aspire [~] file /usr/lib/i386-linux-gnu/libpng.so     
/usr/lib/i386-linux-gnu/libpng.so: symbolic link to `libpng12.so'
krab@aspire [~] file /usr/lib/i386-linux-gnu/libpng12.so   
/usr/lib/i386-linux-gnu/libpng12.so: symbolic link to `/lib/i386-linux-gnu/libpng12.so.0'
krab@aspire [~] file /lib/i386-linux-gnu/libpng12.so.0
/lib/i386-linux-gnu/libpng12.so.0: symbolic link to `libpng12.so.0.49.0'
krab@aspire [~] ldd /lib/i386-linux-gnu/libpng12.so.0.49.0
        linux-gate.so.1 =>  (0xb771f000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb76c2000)
        libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7696000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74eb000)
        /lib/ld-linux.so.2 (0xb7720000)


krab@aspire [~] file /usr/lib 
/usr/lib: directory
krab@aspire [~] file /usr/lib/i386-linux-gnu 
/usr/lib/i386-linux-gnu: directory


krab@aspire [~] cat /etc/mtab 
/dev/sda1 / ext4 rw,errors=remount-ro 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
udev /dev devtmpfs rw,mode=0755 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=0755 0 0
none /run/lock tmpfs rw,noexec,nosuid,nodev,size=5242880 0 0
none /run/shm tmpfs rw,nosuid,nodev 0 0
none /run/user tmpfs rw,noexec,nosuid,nodev,size=104857600,mode=0755 0 0
bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 1)
Ответ на: комментарий от bhfq

Так, теперь я вообще ничего не могу понять. Кто-то может объяснить механизм.

Особенно интересует следующий вопрос:

1) Т.е. устанавливать пакеты от другой архитектуры можно не всегда, а только когда они «заточены» под multiarch.

Т.е. изначально пакеты multiarch собраны таким образом, что пути к библиотекам в префиксах уже указаны.

С другой стороны, можно устанавливать и не multiarch пакеты, но только родной архитектуры, и они живут свoей особой жизнью, как буд-то мультиарча нет вовсе (используют либы из стандартных /lib /lib64 ..... );

ParkeT
() автор топика
Ответ на: комментарий от ParkeT

1) Т.е. устанавливать пакеты от другой архитектуры можно не всегда, а только когда они «заточены» под multiarch.

И, похоже, Debian 7 будет не совсем multiarch, а только в общих чертах, а иначе релиза точно не дождёмся. А я ещё пару недель назад был уверен, что это их цель релиза.

gag ★★★★★
()

Вроде на этом все, но, мне не очень понятно, каким образом система знает какой бинарник( они же теперь могут быть разноархитектурными ), каким ld (из какого префикса) «запускать», по сигнатуре? В общем, тут я немного поплыл, и очень сложно сформулировать вопросы, т.к. они возникают по ходу, но очень хочу понять.

В заголовке ELF'a указан загрузчик. 

$ readelf -a /usr/bin/wine | grep interpreter
      [Requesting program interpreter: /lib/ld-linux.so.2]
$ readelf -a /usr/bin/wine64 | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

AptGet ★★★
()

мне не очень понятно, каким образом система знает какой бинарник( они же теперь могут быть разноархитектурными ), каким ld (из какого префикса) «запускать», по сигнатуре?

«Запускать» можно любой файл, на котором стоит флажок «x». Соответственно, если у тебя два ls (32 и 64), то какой первый встретится в path, тот и запустится. Как уже сказали, у него в заголовке записан «interpreter», который будет натравлен на этот бинарник с целью догрузить нужные библиотеки нужной архитектуры.

no-dashi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Directory junctions в Linux
General
swap при 16 ГБ ОЗУ. →