Pagina asta o voi edita de cite ori schimb lucruri in tfm64. In primul rind pentru a le tine minte.
Sistem minimal 64 este gata . Booteaza , ajunge in prompt. In mare parte pachetele sint aceleasi din tfm-ul vechi cu o exceptie notabila: udev.
kernel 2.6.21.1 , glibc 2.5 , gcc 4.1.2 , perl 5.8.8 , udev 111
Acum urmeaza in primul rind sa adaug mc ( pentru ca merit ) si rpm-ul ca sa pot utiliza o parte din specurile din tfm3.1 ( modificind ce e necesar )
Pachete instalate ( extra base ):
- glib2
- mc
- beecrypt
- db
- expat
- openssl
- neon (are nevoie de downgrade )
- rpm ( fara patch-urile specifice tfm ) ( inca se compileaza )
Bon . Eroare . neon 0.26 nu e suportat direct de rpm 4.4.2 . Prin urmare am de ales: upgrade la rpm ( dar asta inseamna sa imi refac toata partea de autofetch ) sau downgrade la neon pina obtin un rpm functional.
Am sa incerc sa merg pe varianta 2. Probabil ca ma voi lovi de probleme la compilarea de apache si subversion ( am asa un feeling ) .
Continuam compilarea …. Stay tuned
- sqlite (il vrea rpm-ul )
- python ( ln -s python-2.4 pythonauto in usr/include)
Uitasem in /usr/local/lib o librarie veche de libbz2 . Mai mult bzip2 era compilat fara -fPIC ceea ce impiedica rpm-ul sa se compileze corect.
Dupa toate aceste lupte … Avem rpm functional ( fara pachurile de autofetch ). DAR .. se cheama ca sistemul este fuctional . Acuma urmeaza partea complicata . Trecerea incet incet a pachetelor TFM uzuale in noul tree si rezolvarea problemelor care apar.
Booteaza in vmware in 30 secunde.
Cam atit pentru dimineata asta.
06 – 06 – 2007
- sqlite depinde de: ncurses , readline , tcl (optional pentru docs)
- iar rpm-ul are niste faza apropo de x64 …. 3 patchuri pe ziua de azi … se cheama ca sint productiv. Problema cea mai mare a fost la flagurile de compilare.
Si apropo de flaguri de compilare . Petnru tfm64 flagurile default de compilare sint: “-mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC”
Benchmark 1:
compresarea unui ISO de 670065475 cu bzip2
La un bzip2 compilat cu -mtune=k8 -m64 -O2
root@tfm64: 2# time /bin/bzip2 6.2-RELEASE-i386-disc2.iso
real 4m27.183s
user 4m4.919s
sys 0m2.772s
Acelasi fisier compresat cu bzip2 ce a fost compilat cu: -mtune=k8 -m64 -O3 -pipe -fomit-frame-pointer -fPIC
root@tfm64: 2# time /usr/bin/bzip2 t1
real 4m23.154s
user 4m2.083s
sys 0m2.468s
Diferenta de 4 secunde doar din flagurile de compilare.
Ca termen de comparatie , desi e un pic fortat, tfm 3.1 pe un dual xeon acelasi benchmark a dat urmatoarele rezultate:
root@compile: /Tfm# time /usr/bin/bzip2 t1
real 9m51.190s
user 9m42.640s
sys 0m2.930s
Sistemul de instalare va trebui sa permita instalarea din retea . Ce inseamna asta: in retea se pune un server dhcp / bootp si serverul ce urmeaza a fi instalat va boota din retea. Sistemul de boot va trebui sa monteze nfs sistemul pe care exista rpm-urile de instalat dupa care instalarea va continua ca si cum ar instala de pe cdrom.
De ce e necesar ? In momentul in apare necesitatea de a instala multe servere repede in loc sa faci x cd-uri de instalare se pune un singur server si restul se instaleaza via network din el.
16-06:
Inca n-am terminat cu packetele de baza. O gramada de lucruri se schimba la trecerea 32/64 . Initial parea destul de simplu.
Au mai ramas: perl, udev-rules, kernel si de facut bootscripts-ul rpm. Cele mai grele. De ce ? Cu perl-ul am tot avut show-uri ( Ei da … nu-mi place perl-ul DELOC ). udev rules trebuie adaptat la noua versiune de udev. Kernelul. Aici e o parte complicata. Pentru ca trebuie gindit cum fac sa pastrez cit mai mult din structura de tfm32 … initrd …etc
Mai vedem. Intre timp am pus in heavy testing un mysql . Se comporta excelent so far. Zburda.