Linux za Sve forum

time { ./configure ... && make && make install; }

Piše ti, samo u "time" staviš kompajliranje binutilsa. Na kraju ti izbaci vrijeme koje je utrošeno za bildanje binutilsa i to kasnije služi kao orijentir, mjerna jedinica. Gledaš real redak. Možeš i sad vidjeti, samo onako bezveze iskompajliraj binutils unutar time naredbe, ali bez "make install". Dobit ćeš približno vrijeme jer "make install" bude brzo gotov, pa ne utječe previše na ukupno vrijeme. Raspakiraj nanovo binutils arhivu i onda iskompajliraj.

Mislim da bi ovako išlo:

Kod: Označi sve

time { ../binutils-2.22/configure --target=$LFS_TGT --prefix=/tools --disable-nls --disable-werror && make; }

U krajnjem slučaju, ne moraš čak ni "configure" stavljati u "time" jer "make" je taj koji potroši najviše vremena. U tom slučaju kad završi "configure bla..." samo utipkaj "time make" i gotovo. U prvom slučaju dobit ćeš točnije podatke jer su oni mjerili kompletno vrijeme od "configure" do "make install".

Napravit ću, samo da checkiranje gcc-a završi, hvala.

Nema na čemu i

Hvala

drone je napisao/la:Kako BLFS nema package manager, problem je pratiti instalirane programe i njihove depse. Međutim, bildati neki postojeći package manager i onda paketirati svoje programe nema baš previše smisla. Puno je to nepotrebnog posla i pogotovo nije isplativo ako je u pitanju samo jedan stroj.

Zapravo, postoji jedan package manager koji bi mogao biti vrlo upotrebljiv u navedenom slučaju. Napravljen je s (CB)LFS-om na umu, ali može se koristiti s bilo kojom distrom ako se primjerice kompajliraju programi van repozitorija i želi ih se na jednostavan način ipak imati u nekakvoj bazi radi lakše deinstalacije ili nadogradnje.

Zove se Paco (Package Organizer), a s njim dolazi i nekoliko vrlo korisnih skripti pomoću kojih može svakakva čuda raditi uključujući pretraživanje već postojećih instaliranih paketa iz sourcea (koji su instalirani bez upotrebe Paco-a) pri čemu ih uvrsti u svoju bazu. Može instalirati Debian, rpm ili Slackware binarne pakete bez potrebe za dpkg, rpm i pkgtool, te stvoriti binarne tarballe iz postojećih instalacija pomoću informacija iz svoje svoje baze. Ima čak i GTK GUI frontend za neke jednostavnije stvari.

Upotreba je vrlo jednostavna, a svodi se na pozivanje Pacoa prilikom "make install".

Na papiru zvuči prilično dobro, ali ne mogu potvrditi kako se ponaša jer ga nisam koristio. Namjeravam uskoro na pravom hardveru bildati CLFS multilib uz pomoć Pacoa, pa ću provjeriti valja li. Vidim da razvoj Pacoa nije više previše aktivan jer je zadnja verzija 2.0.9 izdana prije nešto više od dvije godine. Nadam se da nije potpuno napušten.

http://paco.sourceforge.net/

Prije svega, hvala "drone".
Uvijek korisne natuknice "natukneš"
You keep us alive, dude

Inače, nisam ni ja odustao (ja sam čak počeo u drugoj temi na ovom forumu, a ne u ovoj, LOL ),
ali u međuvremenu sam imao nekih negativnih razvoja na poslovnom planu koji su se ispriječili,
uglavnom biti ću "!zaposlen" za par dana,
pa ću imati više slobodnog vremena LFS. I tako.

Uglavnom ja sam tek na 6.5 poglavlju po LFS 7.1 book-u.
Ako ništa sad baratam sa tar komandom bolje nego svi članovi "Expendables" zajedno.

Preporuka svima,
LFS je veliki learning experience i ako nejde iz prvog pokušaja, ići će iz nekog od sljedećih ,
a ako zapne i "drone" je tu, jelte

Nisam ni znao da nas toliko ima. Drago mi je zbog toga.
Kažeš !zaposlen. I ja sam već skoro mjesec dana, zato sad i imam vremena za LFS. U svakom zlu, neko dobro

Točno, ako ne ide iz prve ići će iz druge ili treće. Kad je čisti LFS u pitanju, iz vlastitog iskustva mogu reći da u 99% slučajeva problemi se pojave zbog dekoncentracije i propusta bildera. Propusti u samoj knjizi su ekstremno rijetki.

Hvala na podršci.
Stay alive

Nisam jucer stigao, bio sam preumoran, a kao sto kazes, zbog toga i dodje do greske pa bolje ne. Kad se vratim s posla postat cu ovdje gcc log. Vidio sam u terminalu da je checkiranje javilo neki error, nemam pojma sto je, nisam jos gledao log, checkiranje je trajalo dugo pa mi se nije dalo.

Results can be compared with those located at http://www.linuxfromscratch.org/lfs/bui ... velopment/ and http://gcc.gnu.org/ml/gcc-testresults/.

A few unexpected failures cannot always be avoided. The GCC developers are usually aware of these issues, but have not resolved them yet. In particular, the libmudflap tests are known to be particularly problematic as a result of a bug in GCC (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003). Unless the test results are vastly different from those at the above URL, it is safe to continue.

Sorry na običnom cp, ali obrati pažnju. Vjerojatno nema razloga za brigu. Nastavi dalje i ako ne bude problema, ok je.