[Gelistirici] 2011 toolchain vs.

[Onur Küçük]

 Merhaba,

 Bir süredir 2011'in altyapısı için uğraşıyorum. Toolchain in artık
hepimizin kurcalayabileceği hale geldiğini düşünüyorum. Son durum
ve fikirler;

 Şu anda temel sistem olarak glibc 2.12, gcc 4.5.1, binutils
2.20.51.0.10 (tabi ki hepsi bir seri pr düzeltmesi branch güncellemesi
vs. içerir şekilde) olarak hazırlandı. Bir süre daha bu araçlarda
değişiklik yapmaya devam edeceğim.

 Paketlerin son hallerine hem i686 hem x86-64 için [1] adresinden
ulaşabilirsiniz. Ayrıca x86-64 için system.base system.devel derlenmiş
paketleri de yine aynı adreste bulabilirsiniz. i686 paketleri de vardı
ancak onu derlediğim sistemimi bozduğum için ssh çalışmıyor, system.*
paketlerini yükleyemedim, daha sonra yaparım.

 Dizin adı stage2 kalmış şimdi fark ettim, stage2-20100806/ olan
dizindeki dosyaları kurarak sadece yeni toolchain e, stage2-20100807 yi
kurarak ABI kırmış haliyle yeni audit, ppl ve onunla derlenmiş paketler
ve no-add-needed yaması çıkarılmış gcc yi kurabilirsiniz. 

 Sadece stage dizinindeki paketler ile paketinizin (bağımlılıkları da
aynı araçlarla derlendiğini kabul ederek) düzgün derlenip
derlenmediğini takip edebilirsiniz. Dikkat etmeniz gereken önemli
nokta, ilk önce glibc paketini kurmak. x86-64-packages dosyalarını
kurduğunuz sistemde sorunlar yaşayabilirsiniz (örneğin masaüstünüz
açılmayabilir), kobay bir sistemde denemenizde fayda var.

 * binutils: Depodaki pakette hem bfd hem de gold desteği açık,
öntanımlı olarak önceki sürümlerdeki gibi bfd kullanmaya
ayarlı. /usr/bin/ld yi /usr/bin/ld.gold a symlink lemeniz ya da linker
parametresini vermeniz gold kullanmanız için yeterli. Ayrıca gcc de de
plugin olarak kullanılabiliyor olmalı ancak nasıl olduğuna bakmadım.
64bit altında relro ile kullanımda gold da bir seri sıkıntı vardı,
geçen hafta yapılan düzeltmelerle sorunlar düzeltildi, ancak başka
sorun yaşarsanız haber ediniz. Gold un avantajı çok daha hızlı
linklenme sağlaması, dezavantajı gold öntanımlı olarak no-add-needed 
parametresi mantığında çalışıyor. Bir de bir kaç yerde sıkıntısı var
(bir kaç bfd özelliğini desteklemiyor, kernel linkleyemiyor, workaround
u var maxpagesize arttırmak yetiyor, ama mesela kernel boyutunu 8%
büyüttüğü söyleniyor). Gold ile linklenen dosyaları bfd
ile linklenenlerle bir arada kullanabilirsiniz. Paketlerimizde
kurcalayıp son halini biraz tecrübe edelim, herkes bulduğunu paylaşsın,
duruma göre karar verelim.

 LDFLAG larda önceki flaglarımızla devam etmeyi düşünüyorum.
no-add-needed bu ara bayağı bir popüler, yaptığı iş linklenme sırasında
A -> B ye linklenirken B içindeki DT_NEEDED sectionlarını A ya asla
almıyor, yani B nin bağımlılıkları otomatik olarak A ya aktarılmıyor.
Bir güzelliği, B->C ise ama A -> C kullanıyorsa fakat linklenmiyorsa ld
artık "şu dosyaya linklenebilirsin" diye direkt eksik kitaplığı
söylüyor. Ama mesela bu overlink sorununu çözmüyor. Gcc de öntanımlı
açan bir yama eklemiştim ama geri aldım, konuşup karar veririz.

 * gcc : Daha optimize kod üretmek, bazı işlemler için daha hızlı
derleme, plugin desteği vs. nin yanı sıra lto (linker time
optimization, bunun için elfutils system.devel e girdi), graphyte
motoru için harici cloog-ppl, ppl (ve bağımlılığı glpk) kullanımı vb.
yenilikler getiriyor. Ayrıca yeni bağımlılık mpc (libmpc paketi) ve
daha düzgün debug çıktısı elde etmek için libunwind de system.devel e
eklendi.

 C(XX)FLAGS için corporate2 deki 64bit flagların aynısını kullanmayı
düşünüyorum, unwind ile ilgili bir iki flag değişikliği yapabiliriz
(-funwind-tables -fasynchronous-unwind-tables), 2011 ayağa kalktıktan
sonra düzgün bir ortamda inceleyeceğim.

 32bit için mtune=i686 yerine yeni gcc ile gelen mtune=atom kullanmak
bana mantıklı gelmeye başladı. Atom işlemciler instruction set olarak
bayağı bir güncel özellikleri desteklerken hız vs. olarak kırpılmış
oluyor. Götürüsü, i5 işlemcili bilgisayarınızda 32bit kullanırsanız bir
miktar performans kaybı yaşamanız olası (test etmedim, ciddi bir fark
olmayabilir), kabaca gcc generic yerine atom kullanırsak işlemcinin bir
seferde 3 işlem yerine 2 işlem yapabileceğini düşünerek kodu optimize
ediyor. Ancak mtune=atom ile hem atom işlemcili sistemlerde hem de eski
bilgisayarda çalışma göz önüne alındığında daha düzgün kod üretildiği
söyleniyor. Fedora 2 sürümdür mtune=atom ile çıkıyor.

 Bir de artık elf header içine bir PARDUS.OPTs section ekleniyor. Paket
debug la mı derlendi, optimize edildi mi vb. bilgileri buradan
okuyabileceğiz. Farmda derlenen paketleri inceleme yoluna gidersek bu
özelliği kullanan araçlar yazabiliriz. Ya da anlamlı bulmazsak ilgili
yamayı kapatabiliriz.

* glibc : söyleyecek pek bir şey yok, şu anda sadece fedora 2.12
kullanıyor, ancak kararlı sürüm çıktığı ve bir sonraki fedora 2.13 e
gittiği için 2.12 şu ana kadar düzgün gözüktü. 

* Paketler corporate2 altında hazırlandı İsterseniz 2009 altında da
kurup kullanabilirsiniz. Bunu yapabilmeniz için paketlerin sürüm
bilgilerini [2] deki betikle (isim Pardus sürüm 2009) değiştirmeniz
yeterli.

* svn deki 2011 dizinindeki paketlerden gördüğüm kadarıyla sadece
diffutils (conftest), libsigsegv (conftest) ve tar (buffer overflow)
derlenmiyor / derlendikten sonra düzgün çalışmıyor. Arada düzgün
olmayan başka paket olabilir.

* Bundan sonra paketlerin bakımı, sorunlarının giderilmesi,
güncellenmesi gibi işlemleri beraber götürmemiz gerekiyor.Paket
sorunları olabilir, toolchain sorunları olabilir, ancak bunları görmek
için artık daha fazla göz kullanmaya başlayalım. Bir sonraki adım benim
gözümde subversion (ve sudo, ve rsync) a kadar bağımlılıkların
tamamlandığı bir depomuz olması ve oraya kadar paketleri sağlıklı
çalışıp derlenecek hale getirmemiz. Subversion hazır olduğunda da elle
ufak bir hile ile 2009 da yaptığım gibi bir kurulum ISO su
hazırlayacağım.

* Gelişmeler oldukça paketleri aynı dizinlerde güncellemeye devam
edeceğim. 


 Şu an aklıma gelenler bunlar, sorular, fikirler, yorumlar, öneriler,
dondurma ?


[1] http://cekirdek.pardus.org.tr/~onur/2011/
[2]
http://svn.pardus.org.tr/uludag/trunk/scripts/change-distro-tag-in-pisi-files

-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens