Neden `/ lib` ve '/ lib64' ama sadece '' bin '' var?


27

Dizüstü bilgisayarımda:

$ cat /etc/issue  
Ubuntu 18.04 LTS \n \l

Kütüphaneler için iki farklı klasör vardır x86ve x86_64:

~$ ls -1 /  
bin
lib
lib64
sbin
...

İkili dosyalar için neden sadece bir dizin var?

PS Ben de Android ile ilgileniyorum ama cevabın aynı olması gerektiğini umuyorum.


1
Sadece birinde mi? Ben de görmek /binve /sbinorada. Soru nedir? Eğer arasındaki fark hakkında soruyorsun /libve /lib64?
Kusalananda

2
@Kusalananda, demek istediğim, bağımsız bir klasör yok x86_64(hiçbiri için /bindeğil /sbin).
Gluttton

7
IMO OP neden olmadığını bilmek istiyor /bin64.
Arkadiusz Drabczyk

Hem 32 bit hem de 64 bit sürümlere (WINE) sahip olmanın faydalarından yararlanan yaklaşık bir uygulama, farklı adlandırılmış ikili dosyalara ( wine*32ve wine*64) sahip olmak suretiyle etrafına girer .
Ignacio Vazquez-Abrams,

1
@ IgnacioVazquez-Abrams: İkili dosyaları kütüphanelere karşı bağladığınız söylenmelidir, bunun tersi de değil. Bu nedenle, ikili dosyaların 32/64 bitlik tarafından bölümlendirilmesi gerekmez.
smci

Yanıtlar:


25

İlk olarak, neden ayrı olduklarını /libve /lib64:

Dosya Sistemi Hiyerarşi Standart bu ayrı söz /libve /lib64mevcut oldukları için:

10.1. Ayrı kütüphaneler gerektiren birden fazla ikili formatı destekleyen sistemlerde / lib dizininin bir veya daha fazla değişkeni olabilir. (...) Bu, çoklu ikili formatları destekleyen, ancak aynı isimde kütüphaneler gerektiren sistemlerde 64-bit veya 32-bit desteği için kullanılır. Bu durumda, / lib32 ve / lib64 kütüphane dizinleri olabilir ve / lib bunlardan birine bir sembolik bağlantı kurar.

Benim Slackware 14.2 Açık örneğin vardır /libve /lib64 32-bit ve 64-bit kütüphaneler için dizinleri sırasıyla rağmen /libFHS öneririm pasajı gibi bir sembolik bağ olarak değil:

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib/libc.so.6 -> libc-2.23.so
$ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib64/libc.so.6 -> libc-2.23.so

Orada ikisidir libc.so.6içinde kütüphaneler /libve /lib64.

Dinamik olarak oluşturulmuş her bir ELF ikilisi , bu durumda ya /lib/ld-linux.so.2da /lib64/ld-linux-x86-64.so.2:

$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
$ readelf  -a main  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib/ld-linux.so.2]

$ file ./main64
./main64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
$ readelf  -a main64  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Tercümanın görevi gerekli paylaşılan kütüphaneleri yüklemek. Bir GNU yorumlayıcısına, bir ikili dosya LD_TRACE_LOADED_OBJECTS=1veya bir lddsarmalayıcı kullanmadan bile hangi kitaplıkların yükleneceğini sorabilirsiniz :

$ LD_TRACE_LOADED_OBJECTS=1 ./main
        linux-gate.so.1 (0xf77a9000)
        libc.so.6 => /lib/libc.so.6 (0xf760e000)
        /lib/ld-linux.so.2 (0xf77aa000)
$ LD_TRACE_LOADED_OBJECTS=1 ./main64
        linux-vdso.so.1 (0x00007ffd535b3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f56830b3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f568347c000)

Gördüğünüz gibi, belirli bir tercüman kütüphaneleri nerede arayacağınızı tam olarak bilir - 32 bitlik sürüm kütüphaneleri arar /libve 64 bitlik sürüm kütüphaneleri arar /lib64.

FHS standardı aşağıdakiler hakkında şunları söylüyor /bin:

/ bin, hem sistem yöneticisi tarafından hem de kullanıcılar tarafından kullanılabilecek, ancak başka hiçbir dosya sistemi monte edilmediğinde gerekli olan komutları içerir (örneğin, tek kullanıcı modunda). Ayrıca, komut dosyaları tarafından dolaylı olarak kullanılan komutları da içerebilir.

Orada ayrı neden IMO nedeni /binve /bin64bu dizinlerin her iki dosyayı aynı adla olsaydı biz koymak zorunda birşey olduğu dolaylı bunlardan biri arayamadım ki /binya /bin64ilk $PATH.

Ancak, yukarıda sadece kongre olduğunu haber olduğunu - Ayrı varsa Linux çekirdeği gerçekten umursamıyor /binve /bin64. Onları istiyorsanız, onları oluşturabilir ve sisteminizi buna göre ayarlayabilirsiniz.

Ayrıca Android'den bahsettiniz - değiştirilmiş bir Linux çekirdeğini çalıştırmak dışında, Ubuntu gibi GNU sistemleriyle hiçbir ilgisi olmadığını unutmayın - glibc yok, bash yok (varsayılan olarak, elbette manuel olarak derleyebilir ve dağıtabilirsiniz) ve ayrıca dizin yapısı tamamen farklı.


Sizin ls -lörnekler özellikle ilgilidir değildir. Ne olur yararlı olabilir çıkışı olan ls -l /lib /lib64muhtemelen gösteriyor ki, /libkendisi bir sembolik bağdır.
chrylis

Demek istediğin ls -ldve hayır, sistemimde /libbir sembolik bağlantı değil Slackware 14.2.
Arkadiusz Drabczyk

Kütüphaneler farklı md5sums'lere sahiptir: dfd029d25c58831bc5db671aec99a36f /lib64/libc.so.6, 987e7b736f316cc8da87ca2f38dae93e /lib/libc.so.6.
Arkadiusz Drabczyk

2
Bu durumda, sembolik bağlantıları dizinde göstermek alıntıya bağlanmaz.
chrylis

1
LD_TRACE_LOADED_OBJECTS = 1, bir güvenlik boşluğu nedeniyle kullanılmıyor ve ldd artık kullanmıyor. Sebep: ldd / path / to / malware-static-binary, sistemleri devralmak için kullanıldı, çünkü sysadmins tarafından çalıştırılmayan ikili birime bakmak için ldd bekliyorlardı. Ayrıca, statik kontrolü yapmak yerine bir ikili kod kullanmak, bunun yerine kötü amaçlı bir yükleyici kullanmak için oluşturulabilir.
Joshua

22

Bunun nedeni, lib / lib64 dizinlerinin aynı ada sahip dosyaları içermesidir, çünkü bunlar çeşitli programlarla paylaşılan kütüphanelerdir. Onları ayrı dizinlere koymak, çatışmayı çözer. Aynı addaki yürütülebilir dosyaları 32/64-bit olan aynı sistemde dağıtmak için iyi bir neden yoktur, ancak yürütülebilir bir karışım olabileceğinden, paylaşılan kütüphanelerin sağlanması gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.