Gyorsabb portage fordítás

A Gentoo egyik nagy előnye az egyik legnagyobb hátránya is, bár ezt nem kell magyaráznom azoknak, akik már egy ideje használják ezt a rendszert és túl vannak már az első eufórián. Ez nem más, mint az összes program forrásból való fordítása. Ez mindenképpen sok időt emészt fel, akkor is, ha elég erős a gépünk

De gyorsabbá tehetjük úgy, ha a portage nem használja a winchestert! Errre való a ramdisk. A portage a /usr/tmp/portage könyvtárt használja a fordításokhoz az átmeneti fájlok elhelyezésére. Ha ennek a könyvtárnak a helyére mountolunk egy ramdisket, akkor a fordítás a memóriában fog megtörténni és nem a winyót nyúzza.
Ehhez vagy a kézi:

# mount -t tmpfs none /usr/tmp/portage

parancsot használhatjuk, vagy beírhatjuka /etc/fstab fájlunkba, hogy később egyszerűbb legyen előhívni pl így:

[fájl: /etc/fstab]
ptg /usr/tmp/portage tmpfs nodev,nosuid 0 0
[/fájl]

A tmpfs nagy előnye, hogy a tárhely nagysága szükség szerint automatikusan változik. Továbbá ha épp nem tartalmaz semmit, akkor egyáltalán nem foglal memóriát.

De érdemes figyelembe venni, hogy pl egy kdelibs vagy egy openoffice fordítása több, mint 1Gb-t igényel!

Subversion telepítés és repository létrehozás Gentoo alatt

Épp ideje verzió követőt telepíteni, az évek során sokszor hasznos lett volna. Rövid keresgélés után a subversion mellett döntöttem.
Gentoo alatt a telepítés megkezdése egy szempillantás, de azért én szeretek ránézni, hogy mi is fog települni és milyen USE flagekkel:
# emerge -a subversion
A -a parancs az 'ask', tehát nem kezd ész nélkül fordításba, hanem megmutatja, hgoy mit fog fordítani és milyen flagek vonatkoznak rá. Nekem jó, mehet. Bár a neon csomag frissítése még sok másik csomag frissítését vonja maga után, de ez van (aki ezt nem bírja, térjen át Ubuntura...).

Az emerge végén:
* Subversion Server Notes
* -----------------------
*
* If you intend to run a server, a repository needs to be created using
* svnadmin (see man svnadmin) or the following command to create it in
* /var/svn:
*
* emerge --config =dev-util/subversion-1.5.4
*
* Subversion has multiple server types, take your pick:
*
* - svnserve daemon:
* 1. Edit /etc/conf.d/svnserve
* 2. Start daemon: /etc/init.d/svnserve start
* 3. Make persistent: rc-update add svnserve default
*
* - svnserve via xinetd:
* 1. Edit /etc/xinetd.d/svnserve (remove disable line)
* 2. Restart xinetd.d: /etc/init.d/xinetd restart
*
* - svn over ssh:
* 1. Fix the repository permissions:
* groupadd svnusers
* chown -R root:svnusers /var/svn/repos/
* chmod -R g-w /var/svn/repos
* chmod -R g+rw /var/svn/repos/db
* chmod -R g+rw /var/svn/repos/locks
* 2. Create an svnserve wrapper in /usr/local/bin to set the umask you
* want, for example:
* #!/bin/bash
* . /etc/conf.d/svnserve
* umask 002
* exec /usr/bin/svnserve ${SVNSERVE_OPTS} "$@"
*
* - http-based server:
* 1. Edit /etc/conf.d/apache2 to include both "-D DAV" and "-D SVN"
* 2. Create an htpasswd file:
* htpasswd2 -m -c /var/svn/conf/svnusers USERNAME
*
* If you intend to use svn-hot-backup, you can specify the number of
* backups to keep per repository by specifying an environment variable.
* If you want to keep e.g. 2 backups, do the following:
* echo '# hot-backup: Keep that many repository backups around' > /etc/env.d/80
subversion
* echo 'SVN_HOTBACKUP_BACKUPS_NUMBER=2' >> /etc/env.d/80subversion


Valamiért a httpd2 alapú SVN-t választottam. Ez kisebb módosításokat igényel a /etc/apache2/httpd.conf fájlban.


DAV svn
# Nekem a gentoo alapból ide telepíti
SVNPath /var/svn/



DAV svn
SVNParentPath /var/svn


Ezután már el is érhető a repo a böngészőben (nekem készült egy repos nevű repo): http://localhost/svn/repos.
Ha az svnadmin -t használva létrehozunk egy repository-t, akkor az a /var/svn alá kerül be és az előző módon érhető el a böngészőből:
# svnadmin create Teszt

Aztán egy howto meglengette előttem a Trac használatát és én bele is vágtam. Ez egy picit eltolja a dolgok végét, mert a pythont és társait újra kell fordítanom sqlite USE flaggel.

Hm, addig is kis google után belefutottam egy nagy bajba: a gentoo-wiki elvesztette az adatbázisát (miért nem kérik le a lapokat a google-cacheből?!), viszont cachelve megtaláltam az SVN howtot. Mondhatni, talán a legjobb. Igen kár a wikiért! :(


Úgyhogy ennek segítségével el is kezdtem a folytatást: létre kell hozni három könyvtárt.

1. Trunk: ebben lesz mindig a legfrisseb stabil verzió.
2. Tags: Itt vannak a különböző lényegi verzióváltások (v1, v2, v3).
3. Branches: elágazások. Olyan esetekre, ha pl néhány fejlesztő későbbi feautre-on dolgozik. Így az a félkész rész nem kell, hogy bekerüljön a stabil verziókba.

# mkdir /var/svn/Teszt/{trunk,tags,branches}

Én nem tudom, hogy szükséges-e a fájlok tulajdonosának az apache felhasználót megadni, de megtettem (mivel az svn apachként fut nálam).

# chmod apache.apache /var/svn/Teszt/{trunk,tags,branches}

És most jön az első import. Ehhez az importálandó projekt gyökerében kell lenni! (Az importálás kezdete a '.'.)

 # svn import . file:///var/svn/Teszt/trunk -m 'Elso import'

Szerencsésen "Commited 1 revision." a végeredmény. A teszteléshez listáztathatjuk a fileokat:
# svn ls file:///var/svn/Teszt/trunk
Természetesen ezt akár a webszerveren keresztül is intézhetjük:
# svn ls http://localhost/svn/Teszt/trunk

Folytatása következik...

Ruby on Rails

Kezdeti próbálkozások a RoR-el. Persze, rögtön hibába futottam: hiányolta az sqlite3 libraryt. Ez először furcsa volt, hiszen fel volt telepítve, de szükség volt a ruby sqlite3 csatolóra. Ezt feltelepthetjük a ruby saját installerével (gem), de én inkább az portage-t használtam:
# emerge sqlite3-ruby

A RadRailssal való rövid ismerkedés után visszaváltottam a jól megszokott és kiváló JOE szerkesztőre. Hírtelen hátrányának éreztem, hogy nem ismerte a szintaxis kiemelője a RoR-t. De rövid google keresgélés után egy blogon találtam hozzá megfelelőt: itt. Ezúton is köszönöm!

Kis apróság a Rubihoz. Az ismerkedést az Agile Web Developmnet with Rails 3rd edition-nel kezdtem meg és az Ajax résznél hiányoltam valamit: megoldottuk, hogy az Add to Cart-ra kattintva szépen, AJAX módra frissüljön a kosár, de a form_remote_tag -et nem sikerült a képekre is alkamaznom. A megoldást a link_to_remote adta:
<%= link_to_remote (image_tag(product.image_url),
:url => {:action => :add_to_cart, :id => product} ) %>
Ez még bárkinek hasznos lehet akár :D.

RadRails hiba induláskor

Akartam tenni egy próbát a RadRail Studio editorral, de indításkor a kezdő kép bemutatása után hibával kiléppet. A log alapján kezdtem el nekiindulni.
A hiba a logban "!MESSAGE Missing required bundles **még szöveg**".
A hiba oka az volt, hogy 1.7-es Blackhawk java JRE van nálam feltéve. Miután a gentoo eselect parancs segítségével átállítottam a rendszer JRE-jét a még fent levő Sun-jre 1.6-ra, rögtön működni kezdett.

Az AVR-GCC 3.3.6 fordítási hiba elhárítása

Már vagy egy éve nem sikerül lefordítani az AVR gcc-t. Mindig assembler hibával lépett ki, jelezve, hogy nincs egy-két parancs. A gentoohoz ajánlott
# crossdev -t avr
parancsot használtam mindeddig. Sajnos, sehol nem találtam megoldást a problémára. Volt, ahol azt ajánlották valakinek, hogy frissítse a host gcc-t. Uccu neki, én is nekiláttam, de szerencsére az is hibával kilépett a fordításból. Általában itt szokott lenni az a pont, ahol eddig feladtam. De most még hozzátettem egy picit, és a kicsomagolt forrás könyvtárából kezdtem el a fordítást.
Még így sem volt jó sokáig szerencsém, hiába néztem a bug trackereket és google-t.

A hiba:
../../gcc/config/avr/libgcc.S: Assembler messages:
../../gcc/config/avr/libgcc.S:72: Error: suffix or operands invalid for `clr'
../../gcc/config/avr/libgcc.S:72: Error: no such instruction: `clear result'
../../gcc/config/avr/libgcc.S:74: Error: no such instruction: `sbrc r24,0'
../../gcc/config/avr/libgcc.S:75: Error: too many memory references for `add'
../../gcc/config/avr/libgcc.S:76: Error: too many memory references for `add'
../../gcc/config/avr/libgcc.S:76: Error: no such instruction: `shift multiplicand'
../../gcc/config/avr/libgcc.S:77: Error: no such instruction: `breq __mulqi3_exit'
../../gcc/config/avr/libgcc.S:77: Error: no such instruction: `while multiplicand!=0'
../../gcc/config/avr/libgcc.S:78: Error: no such instruction: `lsr r24'
../../gcc/config/avr/libgcc.S:79: Error: no such instruction: `brne __mulqi3_loop'
../../gcc/config/avr/libgcc.S:79: Error: no such instruction: `exit if multiplier=0'
../../gcc/config/avr/libgcc.S:81: Error: too many memory references for `mov'
../../gcc/config/avr/libgcc.S:81: Error: no such instruction: `result to return register'


Az út a megoldáshoz:

Betartottam az install leírásokban láthatókat, annyi a különbség, hogy a crossdev csomagolta ki a forrást és így patchelte is.

# cd [a forrás könyvtárához]
# mkdir obj-avr
# ../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/avr/gcc-bin/3.3.6 --includedir=/usr/lib/gcc-lib/avr/3.3.6/include --datadir=/usr/share/gcc-data/avr/3.3.6 --mandir=/usr/share/gcc-data/avr/3.3.6/man --infodir=/usr/share/gcc-data/avr/3.3.6/info --with-gxx-include-dir=/usr/lib/gcc-lib/avr/3.3.6/include/g++-v3 --host=i686-pc-linux-gnu --target=avr --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libgcj --enable-languages=c --enable-shared --disable-threads --disable-libunwind-exceptions
&& make clean && make all

A configure bemenete egy-az egyben a crossdev logból van. A path-hoz hozzáadtam az avr-binutils bin könyvátrát:
# export PATH=/usr/i686-pc-linux-gnu/avr/binutils-bin/2.16.1:$PATH

Ekkor megszűnik a fenti hibaüzenet és jön helyette egy másik :D

Ez a 14149-es bugban leírt hibaüzenet, amire tényleg megoldás a válaszban található patch
ami azt teszi, hogy a forrás könyvtárban állva a
# joe gcc/config/avr/avr.h
a szerkesztő használatával a
#define BASE_REG_CLASS POINTER_REGS
sort kicseréljük a
#define BASE_REG_CLASS (reload_completed ? BASE_POINTER_REGS : POINTER_REGS)
sorra.

És máris boldogan lefordul a gcc-nk! :D
A telepítéshet:
# make install

MPLAB C30 & Linker és a dsPic30F2020

A mai napnak igen nagy tapasztalata van: sose hidd el a fordítónak egyszerűen azt, hogy nincs watchdog fuse define-olva.
Tehát: a dsPic30F2020 include file-ja állítja az utolsó sorok környékén, hogy a watchdog a
_FWDT(WDT_OFF);
kódsorral kapcsolható ki. De ha ezt használod, a fordító sír, hogy nincs WDR_OFF definiálva. Kis keresgélés után megtalálod, hogy az FWDTEN_OFF valójában. Semmi gond, csak 2 napja optimalizálom a kódot, mert stack OV-tól tartottam a folyamatos, oknélküli resetek miatt. Mostmár beleférne egy F690-esb is :D

Még egy dolog: a disassembly listing. Ez egy annyira kényelmes és kellemes funkció, hogy akik a windows alatti MPLAB-ba integrált C30-at használják, nem is érzik át mennyire hiányzott linux alól. Annyira, hogy arra vetemendtem, hogy átnézzem a C30-as doksikat és a linker beállítások között megtaláljam a megoldást:

# wine /path/a/C30/bin/pic30-objdump.exe -S -d main.o > main.asm

A -S kapcsoló kapcsolja, hogy ne csak sima disassembly legyen, hanem a forráskódot is mixelje bele. Remélem segít másoknak is!
(UI ha nem működik a pic30-objdump.exe, akkor nekem a pic30-coff-objdump.exe-t kellet használni.)

Object Push Server

Az Obextools programokkal sehogy sem sikerült elérni a mobiltelefonról a számítógépre történő küldést bluetoothon.
Átmeneti megoldást jelent az odp program.
Használata:
# opd --mode OBEX --channel 7 --path /tmp/opd --sdp --metadata

Ahol a --channel után a telefon Object push csatorna számát kell beírni.
Ezt az
# sdptool search OPUSH

parancs kideríti nekünk (a telefon legyen bekapcsolva és a bluetooth aktiválva).

Gentoo természetesen ad config fájlt is hozzá, ha az
#emerge opd

paranccsal telepítettük. Ez a /etc/conf.d/opd fájl. Az rc-updattel bekapcsoláskor indítja a rendszer az opd-t.

Tovább keresgélve belefutottam a btfs (Bluetooth FileSystemMapping) Fuse modulba. Sajnos nem a leghasználhatóbb, mert csak küldeni lehet vele az elérhető telefonokra (nekem az sem sikerült), és magát a telefont nem lehet böngészni.

Ezután bukkantam csak rá az obex-data-server-re. Ez már a BlueZ-hez tartozik és erősen integrálják Gnome-ba. Nem érzem jelenleg szükségét, hogy átváltsak rá az odp-ről, de lehet, hogy egyszer még rákényszerülök.

MPLAB C30 és a Linux

Persze, lehet mondani, hogy le lehet fordítani az MPLAB C30 Toolchaint linux alá. De kinek van arra ideje? Szóval marad a wine és a Student Edition (remélem, sose növök fel, mert a 230eFt-s ár azért elég borsosnak tűnik, hiába nem a legmagasabb :) ). És persze a linux és a Piklab :D.

Újra problémába ütköztem, amikor libc-s függvényeket próbáltam hívni (sprintf, malloc), mondván, hogy a linker nem talál meg egy jó csomó objectet. Megpróbáltam windows alól is, na ott ment. Nem volt mást tenni, külső scriptből fordítom a programot.

Jelenleg így hangzik (de szándékomban áll sokat fejleszteni rajta):

#!/bin/bash

wine C:\\MPLABC30\\bin\\pic30-gcc.exe -mcpu=30F4011 -c -x c -IC:\\MPLABC30\\include ./StepperMControl.c -oStepperMControl.o -g -Wall &&
wine C:\\MPLABC30\\bin\\pic30-gcc.exe -Wl,StepperMControl.o,C:\\MPLABC30\\lib\\libc-coff.a,C:\\MPLABC30\\lib\\libm-coff.a,C:\\MPLABC30\\lib\\libpic30-coff.a,C:\\MPLABC30\\lib\\libp30F4011-coff.a,C:\\MPLABC30\\lib\\libdsp-coff.a,-LC:\\MPLABC30\\lib,--script=C:\\MPLABC30\\support\\gld\\p30f4011.gld,-ostep.cof,-Map=step.map,--report-mem &&
wine C:\\MPLABC30\\bin\\pic30-bin2hex.exe step.cof &&
piklab-prog --programmer icd2 --port usb --device 30F4011 --command program step.hex &&
piklab-prog --programmer icd2 --port usb --device 30F4011 --command run

Linux + Wifi fagyás

Amióta wifit használok, folyamatosan fagy a gép random időközönként. Régebben is jelentkezett a probléma a zd1211-es driverrel, de akkor sokkal gyakrabban fagyott, és azonnal magával vitte a billentyűzetet is (az egeret nem). Most csak akkor hal le teljesen, amikor újraindítani próbálom. A Magic Sysreq működőképes marad.

Kernel hack próbálkozások.
2008. 04. 18. CONFIG_TICK_ONESHOT=not set ( Processor types and features-> Tickless system kikapcsolva).
CONFIG_NO_HZ = not set
CONFIG_SMP not set
CONFIG_HIGH_RES_TIMERS not set

Az utóbbikat azért kellett kikapcsolni, mert azok bekapcsolják a CONFIG_TICK_ONESHOT-ot.


Egy-egy bug leírás ezt ajánlotta.
Lássuk!
A következő dolog az a kernel paraméter: nohz=off (
2008.05.17. Sajnos a feljebb megtett dolgok nem hoztak eredményt. A fagyás ugyanúgy kiszámíthatatlan és összevissza.

D900i és a Linux: SIKER

Bár nagyon nagy volt a küzdelem, de sikerült áttölteni linux alatt java programot a D900i-mre!

Hihetetlen rázós volt az út: kernel cserbere. (A legújabb kernelben sikerült az alkotóknak ****** módon átgyúrni a netdevice részt és így nem fordul le a wifikulcsom drivere. A régi kernelben meg pont hibás az iptableshez szükséges rész) Letettem a voksom egy 2.6.23-r11 mellett.

Aztán hosszas keresgélés az iptables használata után. A cél: a ppp0 forgalmát átirányítani, mert a teló 127.0.0.1-es címre küldi a csomagjait (jó furcsa...).

A tudás:

# iptables -t nat -A PREROUTING -i ppp0 -j DNAT --to-destination 192.168.1.100

ahol a 192.168.1.100 a gépem IP címe.

Ezután nincs más dolog, csak a telefonon a "mágikus" *#52828378#-at beütni, belépni a 3 Serial test menüben a 2 Verzió letöltése parancsot választani és már száguld is az adat a telefonra!

Persze, kivéve, amikor nem. Van sok .jar, ami nem akar sehogy sem átmenni a telóra, oka ismeretlen. DE fontos, hogy megbizonyosodj róla, hogy nem fog hibába ütközni az áttöltés (memória tele, már átvett, ilyesmik), mert nem szól róla, csak fagy.

Ha átment a kívánt .jar, a teendő a következőhöz annyi, hogy bemásolod a webservereden levő test könyvtárba a következő .jad fájlt átnevezve getNextApp.jad-nak és a hozzá tartozó .jart (átnevezés nélkül).

A "net/core/skbuff.c:95" kernelhiba

A címben említett kernel hiba igen sokáig elszórakoztatott ma (és talán már tegnap is), mire rávettem maga, hogy rákeressek googlén. Hiszen mégiscsak először máshol keresi az ember a hibát és nem a linux kernelben. De mint kiderült, a hiba ott van.

Épp töltöm az új kernelt, ezért írom a bejegyzést. Mert észre kellett vennem, hogy a suspend2-sources-nak nincs új változata (2.6.22-nél el van akadva, pedig a gentoo-sources már 2.6.24-nél jár). Felmásztam gyorsan a Gentoo hivatalos oldarla és a handbookból kilestem, hogy átnevetnék Tuxonice-nak a suspend2-es kernelt!

TP-LINK TL-WN312G és a Linux

Bár én már réges-rég nem gondolom,hogy mindenkinek linuxot kellene használnia, de picit meglepődtem, hogy a XXI. század elején egy újonnan a piacra törő cég nem ad linuxos drivert az eszközéhez. De, mint mindig, most is meg lehetett találni a megoldást.

Az eszköz csatlakoztatása után az lsusb parancsot használva azonnal szembesülünk vele, hogy az eszköz szívét egy Ralink chipset adja. A gyártó oldalán keresgélgetve (és pici google után), kiderül, hogy jó és megbízható linuxos drivereket ad a Ralink. A Support/Linux menüpont alatt találjuk őket. A minket érdeklő driver a RT2501USB(RT73:RT2571W/RT2573/RT2671)elnevezésű. Letöltjük és kicsomagoljuk.

A Module könyvtárban könnyen elboldogulhatunk:
# make
Majd, ha sikeresen elkészül (nálam gond nélkül fordult):
# make install

Most, hogy mind meglepődtünk a varázsparancsokon :), jön a nagy leleplezés: nem sikerült fordítanom a wpa_supplicantot. De! A wpa supplicant a RT2860PCI/mPCI/CB(RT2860/RT2890) WebUI(WPA_Supplicant-V.0.5.7_Source_Code) driver csomagot felrakva telepít wpa_supplicant-ot.

Ezután már csak a linux wifi rész van hátra.
#iwconfig

A listában meg kell, hogy jelenjen az rausb0 interface. Ha megvan:
#ifconfig rausb0 up

(Ha ezt kifelejted, hibaüzenetet kapsz vissza a következő parancsok futtatásakor, aminek a vége ilyesmi: "...; Network Down".)

Ha a routeren essid van beállítva:
#iwconfig rausb0 essid "Essid_neve"

És kész is vagyunk!
(Nálam még tiltani kellett az eth0-t, hogy menjen, de ez másik eszközökkel is így volt.)

Még egy rc filet kell írni, hogy rendszerindításkor magától induljon.

Megjegyzés: nem sikerült elboldogulnom a gentoo-s init.d -s megoldással.

CCS Compiler és ICD2 Linux alatt

Nagyon nagy örömömre szolgált, hogy sikerült a CCS fordítót működésre bírni linux alatt. Azt előre bocsájtom, hogy az IDE nem működik (és valószínűleg nem is fog).
A PikLab-ot használom már jó ideje linux alatti IDE-nek PIC programozáshoz. Szép is és rugalmasan fejlődik. (A Piklab magába olvasztotta a Pikdev-et is.) Támogatja az MPlab ICD2-t és a Pickit2-t is (és még sok másik programozót). Sok fordítót is támogat. A CCS PICC-t CrossOver Office-on keresztül támogatja a Piklab szerint. Ezen sikerült változtatni és Wine használatával futtatni.

Telepítsük fel a Piklabot. Gentoo esetében található ebuild is, de még nincs bent a Portage treeben, a Piklab oldalról letölthető. Az ebuild telepítését a Third Pary Ebuilds (Külső ebuildek) bejegyzésben már leírtam.

Ezután telepítsük a PICC-t wine segítségével. Lépjünk be a könyvtárba, ahol a PICC telepítő van. Indítsuk el a telepítőt a wine segítségével. Az egyetlen fontos dolog, hogy a PICC-t olyan könyvtárba rakjuk, hogy az elérési útvonalában ne legyen space (üres karakter)! Tehát pl: c:\PICC. Ha nem ide lett telepítve, hanem a Program Files könyvtárba, nem gond, áthelyezhetjük kézzel is, de editelni kell a ccsc.ini filet és átírni az útvonalakat.

# wine pcwhdupd.exe

Kövessük a telepítő útmutatását. Telepítsünk fel minden CCS programot, amire szükségünk van (az MPLAB pluginre többé nem lesz :D).

Meg kell még hackelni a ccsc filet is. Ez Gentoo esetében a /usr/bin könyvtárban található meg.

# joe /usr/bin/ccsc

Én kb mindent kitöröltem, csak két sor maradt (feltételezve, hogy a C:\PICC könyvtárba lett telepítve):

#!/bin/sh
/usr/bin/wine "C://PICC//Ccsc.exe" "$@"

És ennyi. Indítsuk el a piklabot:

# piklab

Válasszuk ki a fordítót az ablak jobb alsó sarkában találjuk meg. Ellenőrizhetjük a működést, ha a "Settings" menüben a "Fordítóprogramok beállításai" parancsra kattintunk és kiválasztjuk a "C compilers" közül a "CCS compiler"-t. Ekkor meg fog jelenni a CCS verzió ablaka, ha mindent jól csináltunk. Innentől már csak az F8-at kell nyomkodni :D

dsPicek:
Ha dsPicet szeretnél programozni, jó esélyed van rá, hogy a piklab 0.15.2-es még azt fogja mondani, hogy a CCS fordító nem támogatja (azt hiszem, hogy a 24F-esekre is). Ezt ne hidd el neki semmiképpen! :) Annyi a feladatod, hogy a Continue gombra kattintassz. És már jön is a hibaüzi. Ennek elkerüléséhez a fordító beállításaihoz (a Project Settingsnél) a fordító meghívását át kell állítani automatikusról és hozzá kell még írni a "+FD" parancssori parancsot.
Ezután is ki fogja írni a Piklab, hogy a CCS nem támogatja, viszont le fog fordulni.

Ráadás: CCS Help
Ráadásként még a PCW súgóit is el lehet érni. A PICC súgófileok .chm formátumúak, ami linux alatt is megnyitható. Én az xchm programot használom erre, de biztos van másik is (ami talán jobb, karakter megjelenítési problémáim vannak néha).
Ezek a súgofileok a C:\PICC könyvtárban vannak, a szokásos online súgó a Ccsc.chm.

# xchm Ccsc.chm

Kereshető, ugyanúgy, mint a windows alatt.

Third Pary Ebuilds (Külső ebuildek)

Természetesen lehetőség van a külső ebuildek használatára Gentoo Linuxon.

Például: piklab-0.15.2.ebuild telepítése
Feltételezzük, hogy a portage tree a /usr/portage könyvtárban van.
Ha ezt az ebuildet hozzá akarjuk adni a saját portage treenkhez, egy PORTAGE_OVERLAY változót kell bevezetnük és a /etc/make.conf fájlba beírni. Enélkül az emerge --sync törölni fogja az általunk beiktatott ebuildeket.
Szövegszerkesztővel nyissuk meg a /etc/make.conf filet.
Adjuk hozzá a következő sort:
PORTAGE_OVERLAY=/usr/portage/dev-embedded/piklab

Ha van már PORTAGE_OVERLAY bejegyzés, használd a következőt:
PORTDIR_OVERLAY="{PORTDIR_OVERLAY] /usr/portage/dev-embedded/piklab"

Ha ezzel megvagyunk, másoljuk az ebuildet ebbe a könyvtárba és lépjünk is oda.
Feltételezve, hogy az ebuild az aktuális könyvtárban van:

# cp piklab-0.15.2.ebuild /usr/portage/dev-embedded/piklab
# cd /usr/portage/dev-embedded/piklab

A forrás letöltése és a manifest file-ok létrehozása:
# ebuild piklab-0.15.2.ebuild

És már mehet is a telepítés:
# emerge piklab