Raspberry Pi'nin kullandığı ARM nesil geçmişine bakınca gerçekten çok eski bir çip olması şaşırtıcı
Raspberry Pi B+’ın çıktığı 2014 itibarıyla bile kullanılan ARM1176 çekirdeği 2003 tarihliydi; yani o sırada zaten 11 yıllıktı
Bu yüzden daha yeni Raspberry Pi gibi başka platformlarda derleme yaparken uyumlu kod üretmek için mimari bayraklarını açıkça belirtmek gerekebilmesi tuhaf değil
Ancak Raspberry Pi B+ üzerinde derlerken bile doğru mimari varsayılan olarak seçilmiyorsa, bu dağıtım varsayılanları tarafında bir yapılandırma hatası gibi görünüyor
Orijinal Pi’nin TV kutularında kullanılıp artan çipleri kullandığını hatırlıyorum
Böyle ürünlerde maliyet nedeniyle gerekenden fazla hesaplama gücü koymak neredeyse hiç olmaz
Zaten baştan ucuz bir bilgisayar olarak tasarlanmış bir üründü
Aslında B+ üzerinde derlenmiş değil
Yazıda “çok daha hızlı bir Pi 4B olan derleme ana makinesinden ikiliyi alıp bu eski cihazda çalıştırmaya çalışınca illegal instruction çıktı” deniyor
Bu, Windows 11’de güncel MSVC ile derlenmiş bir .EXE’yi Windows XP yüklü eski bir PC’de çalıştırmaya benziyor
Muhtemelen Pi 4B’de çalışan Pi dağıtımının tamamı da B+’ta çalışmayacaktır; çekirdek de aynı şekilde derlenmiş olabilir
Yazıda ya da makalede açıkça ele alınmamış gibi, ama bu bir bug değil mi?
LLVM bug’larına bakınca neredeyse aynı sorun gibi görünen bir kayıt vardı ama 2012 tarihli ve kapatılmış. Son birkaç yoruma bakınca aslında düzeltilmemiş de olabilir gibi görünüyordu; ancak sadece kabaca göz attığım için yanlış anlamış olabilirim https://github.com/llvm/llvm-project/issues/13989
Tekrar bakınca yazının sonunda hedef açıkça geçirilirse çalışan bir program çıktığını söylemiş. Öyleyse bir tür yapılandırma bug’ı gibi; Unix’te varsayılan hedefin mevcut işlemci olacağını düşünürdüm ama emin değilim
Bağladığım bug, hedef doğru ayarlansa bile yanlış kod üretilmesiyle ilgiliymiş gibi görünüyor; neyse ki şu anki durum öyle değil gibi
Evet. Bağladığın bug, derleyiciye hedefin armv6 olduğunu söylemelerine rağmen armv7 komutları üretmesi sorunuydu
Rachel’ın sorunu ise derleyiciye hedefin armv6 olduğunu bildirince çözüldü; dolayısıyla o bug zaten düzeltilmiş ve bu sorundan ayrı görünüyor
Elbette bug, ama yazar bunu raporlamak yerine biraz tıklama çeken başlıklı bir blog yazısı yazıp “çok tuhaf” diye bitirmiş gibi görünüyor
Çalıştığım veritabanı ClickHouse, çok eski donanımlarla uyumluluğu korumak için epey çaba harcıyor
Standart ARM ikilisi 2016 tarihli Armv8.2 gerektiriyor ve Raspberry Pi 2 sonrası modellerde kullanılabiliyor. x86 ikilisi ise hızlı CRC için SSE4.2 ve pclmul* komutları bulunan, 2010 civarı donanımlarda çalışıyor
Armv8.0 ve yalnızca SSE2 bulunan sistemler için de ikili derliyoruz ama CI ile test etmiyoruz. Hızlı kurulum betiği, hedef ana makineye uygun ikiliyi indirip arşivden çıkarıyor Geriye dönük uyumluluk ile güncel AArch64 nesillerindeki CPU özelliklerinden yararlanma arasında denge kurmanın genel olarak zor olduğunu düşünüyorum https://en.wikipedia.org/wiki/AArch64
Bütçesi kısıtlı kurumların, örneğin gelişmekte olan ülkelerdeki üniversitelerin ya da donanım yükseltmeye imkânı olmayan hobi kullanıcılarının sayısı şaşırtıcı derecede fazlaydı
Teknik olarak /proc/cpuinfo’daki CPU bayraklarının derleyiciye geçirilen -march= bayrağıyla her zaman birebir örtüşmemesi oldukça uğraştırıcıydı. Örneğin "lrcpc" ve "rcpc" gibi farklı görünüyorlar
Bunu düzgün çalıştırmak için aslında iki tür bayrak kümesini yönetmek gerekiyor
Böyle bir durumda, birden fazla derleme sunup müşterilerin kendi mimarilerine en yakın olanı seçebilmesini sağlamak bence herkesin yararına olur
Sorun büyük olasılıkla bookworm’un mevcut clang-13 paketinde yapılandırılan hedefin değişmiş olması gibi görünüyor
Somut olarak bullseye ve clang-11’de varsayılan hedef armv6k-unknown-linux-gnueabihf iken, bookworm ve clang-13’te arm-unknown-linux-gnueabihf
Ya da LLVM tarafında bu derleme yapılandırmasının varsayılanı değişmiş olabilir
Kasıtlı bir değişiklik olduğunu sanmıyorum
Yakındaki yorumlarda /etc/env.d/gcc’den bahsedildiği gibi, bunun ortamdan bilgi okuma biçimiyle ilgili olma ihtimali epey yüksek
Varsayılan triple, clang daha spesifik bilgi bulamaz veya kendisine iletilmezse arm-unknown-linux gibi bir değer olurdu; daha spesifik hedefi bildiren mekanizma bozulmuş gibi görünüyor
Bu, ARMv6 buildbot olmadığı anlamına da gelebilir; buildbot olduğu ama orada örtük ayarların hâlâ düzgün çalıştığı anlamına da gelebilir
LLVM gerçekten iyi bir çapraz derleyici. Herhangi bir hedeften herhangi bir hedefe büyük sorun çıkarmadan derleme yapılabiliyor
Clang ise buna kıyasla daha az cazip. Hedef desteğiyle derlenmişse ve hangi hedefe derleyeceğini ona düzgünce bildirebiliyorsanız muhtemelen doğru şekilde halleder. Bu yazıda da tahmin yanlıştı, ama daha fazla bilgi verilince doğru çalıştı
Çalışma zamanı kütüphaneleri tarafı daha kötü. armv4 gibi bir hedef için derlemiş olsanız bile ona uygun libc vb. bulmanız gerekir; o kütüphane ve header’ların konumunu derleyiciye bildirmeniz gerekebilir ve bu kısımda ayrıntılar hâlâ net değil
Çoğu dağıtım ve derleyici birkaç yıl önce fiilen ARMv6 desteğini bıraktı
Eski bir Synology NAS için binary derlerken benzer bir sorun yaşamıştım
Clang neden /etc/env.d/gcc’den bilgi okumak zorunda olsun ki?
clang/clang++ hedef bayraklarını ve profilleri /etc/env.d/gcc’den okur; bunları doğru durumda tutmak işletim sisteminin sorumluluğudur
Bu işletim sisteminde bu yönetim düzgün yapılmamış gibi görünüyor
Daha eski armv4 mimarisi tabanlı Gentoo ARM SBC’m, en yeni gcc/clang güncellemelerinde bile hâlâ sorunsuz çalışıyor grep CTARGET /etc/env.d/gcc -r /etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"
/etc/env.d, kullanıcı oturumunun varsayılan ortam değişkenlerini tanımlayan Gentoo’ya özgü bir dizindir
Clang’in o dizini okuma özelliği yok; bu yüzden bunun başka dağıtımlarda da olduğunu varsaymamak gerekir
Sadece Gentoo’nun derleyici ayarı, hedefi seçmek için CTARGET ortam değişkenini okuyor ve Gentoo bu değeri ayarlamak için /etc/env.d’yi kullanıyor
Yazıda bunun Debian mı Raspbian mı olduğu, Debian ise armel portu mu armhf portu mu olduğu belirtilmiyor
Bu bilgi olmadan LLVM’in hangi komut kümesine derleme yaptığını tartışmanın pek anlamı yok. Çünkü bu, LLVM’in yerel hedef ayarına bağlı bir konu
Not olarak, Debian’ın llvm-toolchaim-snapshot paketi hâlâ temel seviye olarak ARMv5T kullanan armel’i destekliyor. Ancak şu anda LLVM’in OpenMP kütüphanesinde ayrı bir hata olduğu için derleme başarıyla tamamlanmıyor
Tuhaf olan, Clang binary’sinin kendisinin Pi B+ ile uyumlu bir komut kümesiyle derlenmiş olmasına rağmen, fiilen Pi B+ ile uyumlu bir komut kümesini hedeflememesi
Bu gerçekten garip. Çapraz derleyici olarak kullanılması beklenmediğine göre, teoride host ile hedef aynı olmalı
Muhtemelen imaj Raspbian’dır. Böyle varsaymamak için bir neden görünmüyor
dpkg-architecture komutunun çıktısını ve /etc/os-release dosyasının içeriğini bilmek faydalı olurdu
Bunlar olmadan yararlı bir yorum yapmak zor
Başlık ne yazık ki sansasyonel
Bu bir varsayılan hedef değişikliği ve clang hâlâ Pi B+ için binary derleyebiliyor
Sadece mimariyi açıkça belirtmek gerekiyor. Bu yüzden başlığı, bunun bir varsayılan ayar değişikliği olduğunu daha net gösterecek şekilde biraz değiştirmek daha iyi olur gibi görünüyor
Hedef makinenin bizzat üzerinde derleme yaparken bile o hedef makine için binary üretemiyorsa, bana o kadar da sansasyonel görünmüyor
ARM’de bir programın neden çalışmadığını debug ederken kabaca böyle bir yaklaşım izlemek gerektiğini görmek ilginç
Konteyner içinde çalışmayan bir Unity Linux build’i var; Docker çalıştırılırken amd64 bayrağı verilse bile Unity mono’nun kullanamayacağı bir sistem çağrısı yapmaya çalışıyor
Bir geçici çözüm bulduğum için henüz debug etmedim. Geliştirme modunu açıp build ayarını mono kullanmayacak şekilde değiştirdim
Bir gün daha fazla şey öğrenmek için tekrar kazmam gerekecek
1 yorum
Hacker News görüşleri
Raspberry Pi'nin kullandığı ARM nesil geçmişine bakınca gerçekten çok eski bir çip olması şaşırtıcı
Raspberry Pi B+’ın çıktığı 2014 itibarıyla bile kullanılan ARM1176 çekirdeği 2003 tarihliydi; yani o sırada zaten 11 yıllıktı
Bu yüzden daha yeni Raspberry Pi gibi başka platformlarda derleme yaparken uyumlu kod üretmek için mimari bayraklarını açıkça belirtmek gerekebilmesi tuhaf değil
Ancak Raspberry Pi B+ üzerinde derlerken bile doğru mimari varsayılan olarak seçilmiyorsa, bu dağıtım varsayılanları tarafında bir yapılandırma hatası gibi görünüyor
Böyle ürünlerde maliyet nedeniyle gerekenden fazla hesaplama gücü koymak neredeyse hiç olmaz
Yazıda “çok daha hızlı bir Pi 4B olan derleme ana makinesinden ikiliyi alıp bu eski cihazda çalıştırmaya çalışınca illegal instruction çıktı” deniyor
Bu, Windows 11’de güncel MSVC ile derlenmiş bir .EXE’yi Windows XP yüklü eski bir PC’de çalıştırmaya benziyor
Muhtemelen Pi 4B’de çalışan Pi dağıtımının tamamı da B+’ta çalışmayacaktır; çekirdek de aynı şekilde derlenmiş olabilir
Yazıda ya da makalede açıkça ele alınmamış gibi, ama bu bir bug değil mi?
LLVM bug’larına bakınca neredeyse aynı sorun gibi görünen bir kayıt vardı ama 2012 tarihli ve kapatılmış. Son birkaç yoruma bakınca aslında düzeltilmemiş de olabilir gibi görünüyordu; ancak sadece kabaca göz attığım için yanlış anlamış olabilirim
https://github.com/llvm/llvm-project/issues/13989
Tekrar bakınca yazının sonunda hedef açıkça geçirilirse çalışan bir program çıktığını söylemiş. Öyleyse bir tür yapılandırma bug’ı gibi; Unix’te varsayılan hedefin mevcut işlemci olacağını düşünürdüm ama emin değilim
Bağladığım bug, hedef doğru ayarlansa bile yanlış kod üretilmesiyle ilgiliymiş gibi görünüyor; neyse ki şu anki durum öyle değil gibi
Rachel’ın sorunu ise derleyiciye hedefin armv6 olduğunu bildirince çözüldü; dolayısıyla o bug zaten düzeltilmiş ve bu sorundan ayrı görünüyor
Çalıştığım veritabanı ClickHouse, çok eski donanımlarla uyumluluğu korumak için epey çaba harcıyor
Standart ARM ikilisi 2016 tarihli Armv8.2 gerektiriyor ve Raspberry Pi 2 sonrası modellerde kullanılabiliyor. x86 ikilisi ise hızlı CRC için SSE4.2 ve pclmul* komutları bulunan, 2010 civarı donanımlarda çalışıyor
Armv8.0 ve yalnızca SSE2 bulunan sistemler için de ikili derliyoruz ama CI ile test etmiyoruz. Hızlı kurulum betiği, hedef ana makineye uygun ikiliyi indirip arşivden çıkarıyor
Geriye dönük uyumluluk ile güncel AArch64 nesillerindeki CPU özelliklerinden yararlanma arasında denge kurmanın genel olarak zor olduğunu düşünüyorum
https://en.wikipedia.org/wiki/AArch64
Bütçesi kısıtlı kurumların, örneğin gelişmekte olan ülkelerdeki üniversitelerin ya da donanım yükseltmeye imkânı olmayan hobi kullanıcılarının sayısı şaşırtıcı derecede fazlaydı
Teknik olarak /proc/cpuinfo’daki CPU bayraklarının derleyiciye geçirilen -march= bayrağıyla her zaman birebir örtüşmemesi oldukça uğraştırıcıydı. Örneğin "lrcpc" ve "rcpc" gibi farklı görünüyorlar
Bunu düzgün çalıştırmak için aslında iki tür bayrak kümesini yönetmek gerekiyor
Sorun büyük olasılıkla bookworm’un mevcut clang-13 paketinde yapılandırılan hedefin değişmiş olması gibi görünüyor
Somut olarak bullseye ve clang-11’de varsayılan hedef armv6k-unknown-linux-gnueabihf iken, bookworm ve clang-13’te arm-unknown-linux-gnueabihf
Ya da LLVM tarafında bu derleme yapılandırmasının varsayılanı değişmiş olabilir
Ancak [1] ve [2] karşılaştırıldığında rules dosyasında “DEB_HOST_ARCH armhf ise LLVM_HOST_TRIPLE’ı armv6k olarak ayarla” şeklinde temiz bir test var; bu da derleme yapılandırması değişikliğini doğruluyor gibi görünüyor
[1] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...
[2] http://raspbian.raspberrypi.org/raspbian/pool/main/l/llvm-to...
Kasıtlı bir değişiklik olduğunu sanmıyorum
Yakındaki yorumlarda /etc/env.d/gcc’den bahsedildiği gibi, bunun ortamdan bilgi okuma biçimiyle ilgili olma ihtimali epey yüksek
Varsayılan triple, clang daha spesifik bilgi bulamaz veya kendisine iletilmezse arm-unknown-linux gibi bir değer olurdu; daha spesifik hedefi bildiren mekanizma bozulmuş gibi görünüyor
Bu, ARMv6 buildbot olmadığı anlamına da gelebilir; buildbot olduğu ama orada örtük ayarların hâlâ düzgün çalıştığı anlamına da gelebilir
LLVM gerçekten iyi bir çapraz derleyici. Herhangi bir hedeften herhangi bir hedefe büyük sorun çıkarmadan derleme yapılabiliyor
Clang ise buna kıyasla daha az cazip. Hedef desteğiyle derlenmişse ve hangi hedefe derleyeceğini ona düzgünce bildirebiliyorsanız muhtemelen doğru şekilde halleder. Bu yazıda da tahmin yanlıştı, ama daha fazla bilgi verilince doğru çalıştı
Çalışma zamanı kütüphaneleri tarafı daha kötü. armv4 gibi bir hedef için derlemiş olsanız bile ona uygun libc vb. bulmanız gerekir; o kütüphane ve header’ların konumunu derleyiciye bildirmeniz gerekebilir ve bu kısımda ayrıntılar hâlâ net değil
Eski bir Synology NAS için binary derlerken benzer bir sorun yaşamıştım
clang/clang++ hedef bayraklarını ve profilleri /etc/env.d/gcc’den okur; bunları doğru durumda tutmak işletim sisteminin sorumluluğudur
Bu işletim sisteminde bu yönetim düzgün yapılmamış gibi görünüyor
Daha eski armv4 mimarisi tabanlı Gentoo ARM SBC’m, en yeni gcc/clang güncellemelerinde bile hâlâ sorunsuz çalışıyor
grep CTARGET /etc/env.d/gcc -r/etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"Clang’in o dizini okuma özelliği yok; bu yüzden bunun başka dağıtımlarda da olduğunu varsaymamak gerekir
Sadece Gentoo’nun derleyici ayarı, hedefi seçmek için CTARGET ortam değişkenini okuyor ve Gentoo bu değeri ayarlamak için /etc/env.d’yi kullanıyor
Yazıda bunun Debian mı Raspbian mı olduğu, Debian ise armel portu mu armhf portu mu olduğu belirtilmiyor
Bu bilgi olmadan LLVM’in hangi komut kümesine derleme yaptığını tartışmanın pek anlamı yok. Çünkü bu, LLVM’in yerel hedef ayarına bağlı bir konu
Not olarak, Debian’ın llvm-toolchaim-snapshot paketi hâlâ temel seviye olarak ARMv5T kullanan armel’i destekliyor. Ancak şu anda LLVM’in OpenMP kütüphanesinde ayrı bir hata olduğu için derleme başarıyla tamamlanmıyor
Bu gerçekten garip. Çapraz derleyici olarak kullanılması beklenmediğine göre, teoride host ile hedef aynı olmalı
Muhtemelen imaj Raspbian’dır. Böyle varsaymamak için bir neden görünmüyor
dpkg-architecturekomutunun çıktısını ve/etc/os-releasedosyasının içeriğini bilmek faydalı olurduBunlar olmadan yararlı bir yorum yapmak zor
Başlık ne yazık ki sansasyonel
Bu bir varsayılan hedef değişikliği ve clang hâlâ Pi B+ için binary derleyebiliyor
Sadece mimariyi açıkça belirtmek gerekiyor. Bu yüzden başlığı, bunun bir varsayılan ayar değişikliği olduğunu daha net gösterecek şekilde biraz değiştirmek daha iyi olur gibi görünüyor
ARM’de bir programın neden çalışmadığını debug ederken kabaca böyle bir yaklaşım izlemek gerektiğini görmek ilginç
Konteyner içinde çalışmayan bir Unity Linux build’i var; Docker çalıştırılırken amd64 bayrağı verilse bile Unity mono’nun kullanamayacağı bir sistem çağrısı yapmaya çalışıyor
Bir geçici çözüm bulduğum için henüz debug etmedim. Geliştirme modunu açıp build ayarını mono kullanmayacak şekilde değiştirdim
Bir gün daha fazla şey öğrenmek için tekrar kazmam gerekecek