Merhaba,
* özgür uncuoğlu [2005-07-01 00:45:18+0300]
mail:~# dpkg --list | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
ii gcc-2.95 2.95.4-22 The GNU C compiler
ii gcc-3.3 3.3.5-13 The GNU C compiler
ii gcc-3.3-base 3.3.5-13 The GNU Compiler Collection (base package)
ii libgcc1 3.4.3-13 GCC support library
sistemde iki versiyon gcc olması program derlerken sorun olurmu?konu
hakkında pek bilgi sahibi değilim.bu yüzden tuhaf olabilir bu soru :-)
Bilakis guzel bir soru, dilim dondugunce anlatmaya calisayim. :-)
Bir Debian paketinin pismemis kaynak halinden, pismis halde sisteminize
kurulmasi surecini iki alt surece ayristirabiliriz (bu sorunun daha iyi
yanitlanabilmesi icin): (1) Paketin insa edilmesi ("build"), (2) Insa
edilmis paketin kurulmasi ("install"). Her iki eylemin de dogru sekilde
gerceklesmesi icin bazi "bagimlilik" sartlarinin saglanmasi gerekiyor.
Bunlardan ilkiyle ilgili olan bagimliliklara "Build-Depends", digerine
ise sadece "Depends" diyoruz. Tipik bir Debian kullanicisi icin onemli
olan bu ikinci tur bagimlilik, tabii APT'in sihiri sayesinde onu bile
hissetmezsiniz.
Kurulum bagimliliklariyla ilgili bir ozellik var. Bir paketin "temel
paketler" ("essential packages") dedigimiz olmazsa olmaz islevler sunan
paketler icin (grep, sed vb.) bagimlilik bildirmesi gerekmez. Benzer
bir durum "insa bagimliliklari" icin de soz konusu. Bazi paketler var,
bunlara "Build-essentials" diyoruz. Bu paketleri insa bagimliliklarinda
listelemek _gerekmiyor_. Peki bu "insa temeli" olan paketler neler, gcc
de bunlar icinde mi?
# Once 'apt-get install build-essentials' gerekir. Paket
# derlemeyecekseniz bunu kurarak sisteminizi sisirmeyin.
grep '^g\(cc\|\+\+\)' /usr/share/doc/build-essential/list
gcc (>= 3:3.3)
g++ (>= 3:3.3)
Goruldugu gibi gcc acik bir surum sarti bildirilerek build-essential
olarak tanimlanmis. Surum sartlari hemen hemen daima onemli bir
problemi onlemeye yonelik olarak bildirilir: ABI (Application Binary
Intercase) uyumsuzlugu. Cok kabaca anlatacak olursam, derleyicinin
urettigi ikilik dosyada islevlerin dahili isimlerinin olusturulmasi,
yani "name mangling" yonteminin degistirilmesi tipik bir ABI degisimidir
(bu bir ornek sadece, bunun disinda durumlar da var).
C ABI'sinin (en azindan i386'da) uzun bir zamandir kararli oldugunu
soyleyebiliriz. Ama C++ ABI'si degisebiliyor ve boyle bir degisim
oldugunda mecburen butun paketleri yeni g++'la ile bastan derlemek
gerekiyor. Debian'da bu tur durumlar "migration" denilen bir sureci
tetikler.
Yukaridaki aciklama soruyu daha genis bir perspektiften (biraz daginik
sekilde) ele aliyor. Daha da daginik bir aciklama yapmaya calisayim.
:-) 'usr/bin/gcc' bir simgesel bagdir ve kendisi de esas itibariyla
(bildirdigi bagimliklarla dogru surumu kurmak icin hazirlanan) bir
"simgesel" paket olan 'gcc' paketi tarafindan saglanir. Olagan bir
senaryoda paketi insa eden Makefile bu derleyiciyi zaten acik halde
cagirmak yerine $(CC) olarak cagiracaktir. Taslarin yerine oturmasi
icin bir kac komut ciktisi:
apt-cache depends gcc | grep Depends
Depends: cpp
Depends: gcc-3.3
Depends: cpp-3.3
ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 7 Aug 6 2004 /usr/bin/gcc -> gcc-3.3
update-alternatives --display cc
cc - status is auto.
link currently points to /usr/bin/gcc
...
Ozellikle yukarida isaret ettigim ABI degisimleri suresince ve/veya bazi
donanim mimarilerinde olusabilecek uyumsuzluk sorunlarini onlemek icin
bazi paketler gcc'nin belirli bir surumunu sart kosabilir. Ama bu cok
rastlanilir bir durum degildir.