A Clang mostantól képes a kernel és a world lefordítására i386-on és amd64-en is

FreeBSD

Újabb fejlesztési mérföldkőhöz érkezett a FreeBSD Clang projektje. Tegnap Dimitry Andric bejelentette, hogy az r212979-es SVN commit-től kezdve elvileg minden további patch nélkül le lehet fordítani a FreeBSD kernelt és world-öt Clang-gel mind i386, mind amd64 architektúrákon.

Elvileg mind a kernel, mind a world telepíthető és megfelelően is fut, de Dimitry azért azt javasolja a kísérletező kedvű egyéneknek, hogy biztos ami biztos, legyen valami backup terv, amivel probléma esetén vissza lehet állni a működő rendszerre.

[ További információk a FreeBSD Clang-gel való fordításához | bejelentés ]

Ezzel konkrétan még mindig az a baj, hogy

a) kb 1 éves, azóta nyilván mind a két fordító haladt (jobb esetben) előre
b) valamint jó lenne egy olyan teszt is, hogy mondjuk lefordítanak valami benchmark progit (valamit, ami azért jó a mai többszálú/többmagos/HT procikon), és nem csak a progi lefordítását, hanem a lefordított benchmark-progik által adott eredményt is megmutatják. (Persze az is lehet, hogy már készült is ilyen, sőt akár olvastam is, de hogy nem emlékszem rá, az biztos.)

Ja, meg kérdés, hogy mikor lesz backportolva ez az (elvben utolsó) módosítás - meg persze az összes ami ehhez kellett még, szóval mindezek mikor jelennek meg 8-asban.

Kb. 10%-kal lassabb jelenleg a clang altal forditott binaris -O3 eseten. -O0 es -O1 korul nincs lenyeges differencia. (gcc44-ig, utana mar nem erdekelt.) Viszont clanggal merfoldekkel kenyelmesebb fejleszteni, nem hogy normalis hibauzeneteket kepes generalni, de meg olyan akar melyanalizissel kimutathato problemakra is kepes ravilagitani ami gcc-tol olyan messze van mint Mako Jeruzsalemtol.

---
pontscho / fresh!mindworkz

Ket dolgot felejtesz ki, clang fenyevekkel kenyelmesebb/hasznalhatobb fejlesztoi eszkoz (plane CSA-val megfejelve) mint a gcc, valamint eroteljes fejlesztes alatt all. Lesz ez meg jobb is, de mar az elso ok miatt is boven megeri egy ilyen project mint amibe a FreeBSD-nel belevagtak, masnem a "release" forditasa gcc-4.5 -O3-mal tortenik meg ha nagyon szukseg van arra a plusz 3-10%-ra. Az esetek nagyobb reszeben viszont inkabb a stabil megbizhato mukodes fontosabb, mint az a nehany szazalek.

---
pontscho / fresh!mindworkz

ok, kifejtem bővebben:
1. ha már eddig eljutottak a clangosok, itt már nem fog szerintem bedőlni a projekt, tehát azt hiszem, hogy előbb-utóbb ebből rendes cucc lesz.
2. én hiszek a szabad szoftverben, de amit stallmannék művelnek vele, az, szerintem, egyre kevésbé szabad szoftver. Egy debianban gyakorlatilag a fejlesztői részek azok, amik vagy ténylegesen gnu cuccok, vagy legalább érintőlegesen közük van a gnu-hoz, de egy halom fontos cucc, pl. X, TeX, a kernel, adatbázis, web szerver, és még hosszasan sorolhatnám, nem gnu cucc. A gnome is meg bírna lenni gnu nélkül szerintem.

ha a gcc-t kivágnák a linux disztrókból, akkor egyre kevésbé lenne indoka stallmannak azon pattogni, hogy ez a kernel gnu/linux kernel, mikor nem az, csak némi tiszteletadás okán lett gnu. kiderülhetne, hogy egy linux disztrót is össze lehet rakni gnu cuccok nélkül.

és akkor rms-nél lenne indokolt a faceplam.

a gpl nácikkal kapcsolatban most hétvégén telt be nálam a pohár, amikor azt találta írni valamelyik elmeháborodott, hogy a gnu mailutilst nem használhatom postgreses hitelesítéssel, mert a postgresl nem gnu tls-t használ hanem opensslt vagy mit... semmi köze hozzá, hogyha én nem titkosított kapcsolattal érem el a postgrest, akkor milyen libet nem linkeltem hozzá.

1. ha már eddig eljutottak a clangosok, itt már nem fog szerintem bedőlni a projekt, tehát azt hiszem, hogy előbb-utóbb ebből rendes cucc lesz.

5 éve aktívan szponzorálja és használja az Apple (Chris Lattner az LLVM projekt atyja is 2005 óta Apple alkalmazásában áll), egy rakás saját cuccuk alapszik LLVM/Clang-on (pl. iPhone devkit), úgyhogy kicsit alulértékel[t]ed szerintem... :)

+1

LLVM (+ clang) nagyon jo cucc - bar nekik is megvannak a maguk hibai, mint mindennek. Es nem csak azert, mert onmagaban jo, hanem mert azzal hogy feltunoben van egy gcc alternativa, a gcct is serkenti, vagy legalabbis kellene neki. Igy kb mindenki jol jar, imo.

Ami nekem szimpatikus LLVM-ben, az az, hogy lehet a segitsegevel olyan projectet csinalni, mint pl az Emscripten, es nem lonek le erte. (Jelzem: gozom nincs mire jo a c/c++ -> javascript fordito kisgyerekek riasztgatasan kivul, de szerintem nagyon nagy poen.)

ha a gcc-t kivágnák a linux disztrókból, akkor egyre kevésbé lenne indoka stallmannak azon pattogni, hogy ez a kernel gnu/linux kernel, mikor nem az, csak némi tiszteletadás okán lett gnu. kiderülhetne, hogy egy linux disztrót is össze lehet rakni gnu cuccok nélkül.

Csak a pontossag kedveert: Nem a kernelre mondjak hanem az egesz oprendszerre. GNU userland, Linux kernel.
Van pl. debian GNU/kFreeBSD is, ami egy freebsd kernel gnu kornyezettel.

GCC-n kivul meg rengeteg gnu cucc van linux distrokban: gsed, gawk, gfind, gmake, bison, flex, gpatch, diffutils, coreutils (cp-tol kezdve ls-ig minden alap parancs) .....

Na most eltudod kepzelni ha valaki ezekre epit anelkul, hogy erdekelnek a szabvanyos(POSIX) megoldasok az mennyire lessz gnu/linux specikus es mekkora szivas lessz azoknak akik nem ilyen kornyezetben akarjak hasznalni.

A kerdes megmarad: minek?

Azon kivul hogy lehetne rohogni, hogy "HAHA, RMS erre most nem mondhatja, hogy GNU/Linux!".. es akkor mi van? Van N+1 masik ami viszont igen.

Egyebkent talalkoztam mar olyan linux "distribbel", amiben a linux kernel volt az egyetlen GPL-es cucc. Volt rajta egy sash meg 1-2 BSDs util, es ennyi.

Van par dolog, ami szerintem hasznos GNU extension a POSIX szabvanyhoz, es esetleg erdemes lehet atvenni. Olyan alapveto dolgokra gondolok, mint a sed, grep meg a tarsainak par kapcsoloja.

Nyilvan nem azt mondom, hogy esz nelkul, es mindent, de akkor is: van a POSIX szabvanyon tul is elet.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Van egy fontos kulonbseg. A bongeszo kiterjesztesek nem azert rosszak, mert kiterjesztik a szabvanyt, hanem mert elsosorban a belso motorjaik miatt terjesztik ki, es legtobbszor egy mar letezo szabvany helyett implementaljak egyeni modon. Sot, van sok olyan nem-szabvanyos feature, amibol kesobb szabvany lesz.

Azert a grep-en egy plusz kapcsolo baromira nem ugyanez a kategoria.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A pontosság kedvéért: a kernelre azért kezdték el mondani, mert RMS pattogott, hogy ha már gnu cuccokkal fejlesztik a kernelt, akkor miért nem gnu/linux a kernel. Linus meg nem akart vitatkozni, hát engedett...

Tehát a debian duplán gnu, mert a kernel is gnu/linux, meg az userland egy része is gnu.

"GCC-n kivul meg rengeteg gnu cucc van linux distrokban: gsed, gawk, gfind, gmake, bison, flex, gpatch, diffutils, coreutils (cp-tol kezdve ls-ig minden alap parancs) .....": erre több mindent is lehetne válaszolni:
-awk-ból debianban tudtommal három van, nawk, mawk és gawk. Ezek közül tessék találgatni, hogy melyik awk verzió az, amelyiknél a 16-os számrendszer 13 számból állt.
- a fenti listán felsoroltakon kívül nem is tudom, van-e még komoly gnu cucc a debianban...

sokkal kevésbé tudnám elképzelni a debianomat mondjuk X nélkül, mint gnu awk nélkül...

lessssszzz?

A pontosság kedvéért: a kernelre azért kezdték el mondani, mert RMS pattogott, hogy ha már gnu cuccokkal fejlesztik a kernelt, akkor miért nem gnu/linux a kernel. Linus meg nem akart vitatkozni, hát engedett...

Akkor bocs, errol nem tudtam. Azert megdobhatnal egy linkel, hogy rohogjek egy jot.
Mondjuk az openbsds akcioja utan, mar semmin se csodalkozom. :)

- a fenti listán felsoroltakon kívül nem is tudom, van-e még komoly gnu cucc a debianban...

Hat ne vard, hogy felsoroljam az osszeset egyenkent... de pl ottvan meg grep, groff, gzip, autotools, m4, tar, cpio, binutils, bash es meg egy rakas

Lasd: http://www.gnu.org/software/software.html

Jesszus....
a debian lennyben 28278 csomag van.
azon a linken van vagy 383 csomag.
ne kelljen már hangosan röhögni azon, hogy grep-et meg hasonló apróságokat emlegetsz, miközben apacs, postgresql, mysql, tex, X meg hasonló cuccok vannak, amik közül nagyon soknak még a licensze *SEM* gnu.

grep: szerintem ha nem ragaszkodunk a lefordított c kódhoz, perlben egy jobb programozó akár 15 perc alatt is összeüt egy grep helyettesítést.
gawk: mint már említettem, kukában a helye, maradjunk a mawk-nál
gzip: régen nem használom, van helyette bzip2. upsz, ennek bsd licensze van...
bash: most erőlködnek a debianosok, hogy kihajítsák, mert túl sok erőforrást zabál. helyette a dash-t erőltetik, az meg honnan is jött... netbsd-ből...
cpio, tar: van solarisban is, bsd-ben is, ráadásul a tar nem is kompatibilis teljesen a gnu tarral.

szóval másképp fogalmazok: a gcc-t meg a libc-t leszámítva szerintem semmi gnu cucc nincs a debianban, amit ne lehetne pikkpakk helyettesíteni. A gnu nácik fizetését meg kezeljék olyan psql-lel, amihez nem volt szabad ssl-t linkelni...

http://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

Ahh elbeszelunk egymas mellett.

Nem azt mondtam, hogy nem lehet lecserelni ezeket, hanem hogy legtobb distroban ezek a gnu toolok az alaprendszer resze es ha az ezekre epitett cuccok mashol nem futnak akkor nem az a masik rendszer lesz a szar... Ugyan ugy ahogy egy gcc specikus kod, ha nem fordul le clang-al akkor az nem clang hibaja.

ne kelljen már hangosan röhögni azon, hogy grep-et meg hasonló apróságokat emlegetsz

Felolem rohoghetsz, de attol meg ott lesznek az alaprendszerben.

miközben apacs, postgresql, mysql, tex, X meg hasonló cuccok vannak, amik közül nagyon soknak még a licensze *SEM* gnu.

Meg szerencse. Egyebkent a licence GPL, nem GNU. En eddig egy szot se szoltam licencekrol, csak komptaibilitasrol beszeltem.

másképp fogalmazok: amit írtál, az azt sugallja, mintha egy debianban az fsf projektek által fejlesztett cuccok lennének többségben, holott, szerintem nem azok.
Azok a cuccok, amik az én szememben fontosak, nem fsf projektek, gyakran nem is gpl-esek. És közben (óhajtásként, nem tudományos tényként) kifejeztem, hogy örülni fogok neki, ha a gcc-t ki lehet majd szórni egy linux kiadásból, mert akkor rms-nek kisebb lesz az arca.

a fő különbség a mawk meg a gawk között, hogy anno (nem mostanában) egyszer nekiálltam komolyan gawk-ban programozni és majdnem minden nap találtam benne valami idegesítő hibát. ez ment pár hónapig, utána leszoktam a gawk-ról. A csúcs az volt, amikor kiderült, hogy a d,e,f betűk hiányoznak a 16-os számrendszert kezelő rutinokból. Azóta nyilván beletették, mert küldtem nekik bugreport.

Az tény, hogy a dash messze van a bashtól, de ezt a debianosok előnyként értékelik, és valójában nem le akarja cserélni, hanem már lecserélte a squeezeben.

ha az sh link a dashra mutat, akkor szerintem a dash az alapértelmezett shell...

ilyen bajaim vannak:
- legutolsó bajom: triviálisan nem tudod megoldani, hogy a gnu mailutilsban levő pop3 szerver postgresből autentikáljon, mert a gpl nácik szerint nem lehet a kettőt összelinkelni. persze, meg lehet oldani, csak annyit nekem nem ér
- az alapértelmezett debian install nem teszi fel például a broadcom hálózati kártyák firmware-ét, ami elég gyakori hardver a szerverekben. ez egy hülyeség, hogy nem lehet a kernelben nem gpl-es cucc, a firmware miért ne lehetne benne?
- egyébként pedig a gpl elég szigorú és restriktív licensz, szerintem több jobb is van nála...

nem sorolom.

akkor ott van valamelyik BSD os mint licenc szempontjából elfogadható alternatíva számodra.

ezen kívűl szerintem nem gondolnak bele sokan, hogy valószínűleg oka volt hogy GPL licencet választott a fejlesztő, nem úgy állt neki, hogy akkor lássuk csak, milyen másik licenccel tudok kompatibilis lenni?

ha már BSD licenc, vagy még szabadabb meghatározás kell, akkor tegyék már ki az adott kódot public domain alá, és ne legyen sírás szegény hardver gyártók miatt (ahogy a legtöbb GPLv3 kritizáló site a neten) hogy a gyártók nem tudják minden további megkötés nélkül felhasználni a kódot?! szegények, én mondom, erre egy szakszervezetet kellene létrehoznia az összes nagyhalnak, és eltörölni a földről a GPL-ben leírtakhoz hasonló törekvéseket! vagy miért is nem írják meg maguk? ;)

az hogy fúj fsf vagy fúj rms megértem. viszont úgy gondolom, hogy ha már szabaddá teszi valaki egy fejlesztés kódját, az egyetlen dolog ami pluszt jelenthet és/vagy az innovációkat is visszajuttathatja, hogy ha ezt kikötjük a licencben. ismét leírom, ha már BSD-re adja valaki a fejét, akkor miért ne public domain?? csak a neve miatt a copyright-ban? ez miatt van értelme? vagy ha ez kell, akkor visszacsatolva miért ne GPL például?

olyan érvet tudnék elképzelni, hogy ha pl. BSD licencű az adott kód, akkor többen fogják felhasználni, aztán majd kegyesen visszajuttatni a fejlesztéseket ha úgy akarják. ez tényleg jó lenne? és tényleg működhet? ha valaki már ezért használ fel BSD és hasonlóan engedékeny oss licencet, nem lehet hogy nagyrészt ott már pont érdeke, hogy a hozzá adott további fejlesztések és értékek ne jussanak ingyen a konkurrens gyártók kezére?

nem lehet hogy pont a GPL miatt folyik több kód vissza vagy bele a linux kernel-be is például?

"ezen kívűl szerintem nem gondolnak bele sokan, hogy valószínűleg oka volt hogy GPL licencet választott a fejlesztő, nem úgy állt neki, hogy akkor lássuk csak, milyen másik licenccel tudok kompatibilis lenni?"
Kozkeletu tevedes. A fejlesztok... hmmm... mondjuk legalabb hetvenot szazaleka nem ert a licenszekhez. A GPL szerintem azert lehet nepszeru, mert ennek a nevet eleg sokfele hallani. Es amit sokan hasznalnak, az csak jo lehet, nem igaz?
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

kellett nekem egy pop3 szerver, ami mbox fájlokat szolgál ki és postgresből autentikál. eddig teapop volt, egyszerű, kicsi, jó, de kigyalulták a debianból, mert 2003-as az utolsó verzió belőle. azért használok debiant, hogy fel tudjak tenni mindent repóból, hogy ne legyen gond a frissítés.

máshol használtam courier imapot, gondoltam, adok egy esélyt a courier pop3-nak. de az hamar kilőtte magát, mert maildirt akart mindenáron.

jött a következő, a gnu mailutils. a debianos csomagban van pop3 szerver, ami tud mysql-ből autentikálni, de postgres nincs. gondoltam, lerántom a debianizált forrást, beletúrok kicsit és lefordítom újra. erre egy olyan szöveg fogad a readme-ben, hogy mivel a postgres nem gnutls-t használ, hanem openssl-t, ami nem gpl-es, ezért nem szabad összelinkelni gpl-es programmal. Ahhoz, hogy a gnu pop3 szerver hozzá tudjon kapcsolódni postgreshez, szerintük mindenképpen kell valami ssl szerűség, tehát szerintük csak úgy lehet összelinkelni a gnu pop3d-t a postgres kliens könyvtárakkal, hogy mindenképpen legyen benne ssl. De a postgres miatt ez csak openssl lehet, azt a gpl nácik nem tűrik, tehát úgy van összefaragva a debianizált forrás, hogy pikkpakk nem lehet postgres klienssel is összefordítani. Annyit meg nekem nem ért, hogy rendesen kibogarásszam, hogy lehet-e és mennyi erőfeszítéssel, ment az egész a levesbe.

Kedves gpl nácik, ugye csuklik a kedves mama?

ezért lett dovecot pop3d, ami egy közepesen ótvaros megoldás, de a semminél jobb.

Hűha! Először is, el vagyok képedve, hogy csak azért kivágtak valamit a debian-ból, mert régen volt belőle utolsó verzió. A 2003-as változat bőven lehetett nagyszerűen hordozható kód, vagyis nagyjából védett a "code rot"-tal szemben. Ha nem voltak vele szemben súlyos upstream bug-ok, akkor minek dobták ki? Popcon-ban nem állt jó helyen?

Azt persze megértem, hogy belső csomagokra alapozol; egyébként nem lehet követni a biztonsági frissítéseket.

A mailutils-t letöltöttem a GNU-tól; annak az (upstream) README-je simán említi a postgres támogatást. Úgy látom, az upstream mailutils a postgres-nek szentel egy configure opciót!

Megnéztem a debian csomag README-jét, és valóban. Itt találtam további infót:

Az tiszta sor, hogy bináris formában nem lehet együtt terjeszteni, hiszen az összelinkelt program mindkét eredeti forráskódnak származtatott műve (származéka), amelyre így mindkét licensznek vonatkoznia kellene. Mivel a licenszek ellentmondanak egymásnak, azért ez nem terjeszthető.

Azt azonban semmi sem tiltja, hogy bináris csomag helyett (a forrásból forduló kernelmodulok mintájára) olyan lehetőséget nyújtsanak, hogy helyben fordítsd a binárist. Ez a bináris egyáltalán nem terjeszthető, de ha nem terjeszted, csak használod, akkor tökéletesen kielégítetted mindkét licenszt. A GPL-ben a fenti első link szerint a 6. pont a problémás. De ez a pont így kezdődik: Each time you redistribute the Program. A kombinált, származtatott művet itt senki sem terjeszti, az a te gépeden áll elő. A GPL definíciós része szerint "The Program" refers to any copyrightable work licensed under this License. Nyilvánvalónak látszik, hogy a GPL-es "Program" (így, nagybetűvel) a mailutils, amelynek a terjesztésekor viszont minden be van tartva.

Van egyébként olyan vélemény is, és én hajlok osztani, hogy ezt még a dinamikus linkelés is kielégíti! Hiszen a hivatkozó kliensalkalmazás csak függvényneveket tartalmaz, a lib kódjából nem hordoz semmit. Az az ember gépén áll elő, és a derivative work egyáltalán nincs terjesztve. Bármilyen olyan shared lib, ami sikeresen feloldja ezeket a hivatkozásokat, működőképes programot és külön-külön derivatív művet hoz létre. A kombinált mű "dynamic load time"-kor keletkezik.

Gondoljunk vissza a LessTif/Motif kettősre. A LessTif wp-s cikkelye szerint LessTif aims for full source and binary code compatibility with Motif. Akkor ha fogok egy Motif-ot használó GPL-es programot (amelyet a saját gépemen statikusan linkelve is futtathatnék, de persze aztán nem terjeszthetném), dinamikusan linkelem, és a feloldatlan bináris ELF-et terjesztem (nyilván a GPL-es kliensprogram forrásával együtt), akkor arra vajon mi vonatkozik? A Motif licensz, mert a program hivatkozásait az is fel tudja oldani? A LessTif licensz, mert az is? Vagy kizárólag azon források licenszei, amelyek statikusan (.o-ként) bele lettek linkelve a binárisba? Nyilván az utóbbi, hiszen csak az került terjesztésre!

Szerintem ezt a Debian-nál puszta preventív paranoiából túllihegték.

gplfaqban van ilyen rész:
"If I port my program to GNU/Linux, does that mean I have to release it as Free Software under the GPL or some other Free Software license?"
... "Some libraries are released under the GNU GPL alone; you must use a GPL-compatible license to use those libraries.". ez azért gáz, mert pl. a readline lib az gpl-es, nem lgpl-es.

"Szerintem ezt a Debian-nál puszta preventív paranoiából túllihegték.": nem tudom, ki lihegte túl, rms, a debian vagy ki, de egy magából teljesen kifordult idióta helyzet lett az eredménye.

A teapoppal meg az lehet a gond, hogy nem 64bit clear a kód (legalábbis nekem mindenféle trapeket írt a logba és el-elszállt, mikor használni akartam, azt nem nyomoztam ki, hogy azért szállt el, mert drbd lett alatta, vagy más miatt. lefordulni lefordult a régi csomag, ezzel nem volt gond).

Én a mawk-ot ugyanazért szeretem, mint a dash-t: elsődleges céljuk a POSIX kompatibilitás (ha jól sejtem), ezért terjesztendő script-eket ezekkel érdemes tesztelni/használni. A GNU változatok (gawk, bash) interaktív munkára meg saját használatú script-ekhez nagyon kényelmesek, de másokhoz is eljutó kódban szerintem nem érdemes ezeknek a sajátosságaira hagyatkozni.

a kernelre azért kezdték el mondani

Ne haragudj, tévedsz. A kernelre nem mondják, hogy "GNU/". (Legalábbis akinek egy csepp esze van.) Azt szokták mondani, hogy "Linux (the kernel)", és pontosan azért, nehogy valaki pattogni kezdjen, hogy "GNU/Linux", amikor a beszélő valóban a kernelre gondolt.

Köszi.

Egy gyors, nem mérvadó, számomra érdekes teszt egy 2 magos FreeBSD 8.1 amd64 rendszeren, ahol 1 magon futott egy relative számítás igényes tiszta C kód egyéb függőség nélkül (közel fél GB-os memória használattal), ramdisk-ből futtatva, -O2 optimalizációval (többre most nincs időm):

clang --version
clang version 1.1 (branches/release_27)
Target: x86_64-portbld-freebsd8.1
Thread model: posix

gcc --version
gcc (GCC) 4.2.1 20070719 [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc:
1:00.18
1:00.15
1:00.14

clang:
00:56.41
00:56.41
00:56.43

(gcc) 60.157s +/- 0.038% hiba <---> (clang) 56.417s +/- 0.023% hiba

clang 7.14% -kal gyorsabbnak jött így ki.

( pepo v | 2010. 09. 23., cs – 11:16 )

OFF: Akkor most felül lesz az Antarktisz? ;) :OFF

Hát tekintettel arra, hogy a mai linuxos-szoftvereket fejlesztők jelentős többségének gőze nincs arról, hogy Linuxon túl is van élet, és azért még el fog tartani egy darabig, mire a különböző Linux disztribekbe bekerül a CLang (vagy akár a PCC), ez azért még odébb van. Ugyanis sajnos baromi sok olyan izé van a ports-ban, ami ilyen fejlesztők terméke.

(És hogy elejét vegyem a kérdezősködésnek: igen, már fordult velem elő az, hogy portoltam szoftvert különböző oprendszerek között; sőt olyan is, hogy a javításokat/egyéb módosításokat megküldtem a szerzőnek. Kedvencem az a f@sz, aki kedvesen azt válaszolta, hogy ő nem érti, miért nem elég a világnak az Ubuntu. Persze a felvetett dologra érdemben nem reagált.)

Jellemzoen Zahy altal emlitett tipusu gyerekekkel van a problema. Ok pedig linux korul tornyosulnak es nagy ivben tesznek arra, h vannak szabvanyok, szokasok, interoperabilitas, satobbi es meg arogansak is mert annyira menok, hogy egy gcc-t mar fel tudnak parameterezni linuxon. Ha normalisan es esszeruen kodolsz le valamit akkor az gond nelkul fog fordulni mind gcc-vel, mind clang-gal.

Pont tegnap jartam a fent leirt modon az oidentd-vel. Mar sirni sem volt kedvem mikor atneztem a ports-ban levo patch set-et, hogy mi valtozik forditaskor, h leforduljon, pedig a latest stable kilometerekre orditja magarol, hogy freebsd kompatibilis.

---
pontscho / fresh!mindworkz

oké, de van egy forrásod a portsban. az a forrás valahogy már "idomítva" lett bsd szabványokhoz, akár úgy, hogy az eredeti szerző normálisan írta meg, akár úgy, hogy egy bsd-s karbantartó megírta a portoláshoz a patchet. ezek után az a cucc fordul gcc-vel bsd-n.

ha a clang tisztességes helyettesítője akar lenni a gcc-nek, akkor ezeket a forrásokat szerintem le kell tudnia fordítani, egy kivétel van, ha a gcc maga programozói hiba miatt eltér a szabványoktól és emiatt "elhúzta" a szabványtól a forrást is.

másrésztől meg ha egy program forrása nincs felkészítve bsd-re, akkor az gcc-vel sem fog lefordulni.

én ezt nem linuxos problémának látom. hmcs-k sajnos mindenhol vannak...

ha a clang tisztességes helyettesítője akar lenni a gcc-nek, akkor ezeket a forrásokat szerintem le kell tudnia fordítani, egy kivétel van, ha a gcc maga programozói hiba miatt eltér a szabványoktól és emiatt "elhúzta" a szabványtól a forrást is.

Ez nem is volt vita targya, a gyakorlatban is igy van. Futottam mar bele olyan kodba amit gcc csak -O0-val volt kepes mukodo binarissa alakitani clang meg rohogve oldotta meg a problemat.

másrésztől meg ha egy program forrása nincs felkészítve bsd-re, akkor az gcc-vel sem fog lefordulni.

Sok esetben nem is ez a problema. Hanem hogy a sok suti ott is inkabb linux specifikus kodot alkalmaz ahol van normalis, szabvanyos megfeleloje a problemanak es nem kotelezo taknyolni. Amikor pedig fel van ra hivva a figyelmuk akkor kozlik, h ez igy jo, hulye vagy, nem ertesz hozza es kulonben is a BSD baromsag. Aztan csodalkoznak ha el vannak kuldve melegebb eghajlatra hangos rohoges kozepette.

Jo pelda erre a tegnapi problemam, az autoconf-fal gyartott Makefile olyan jol sikerult, hogy csak es kizarolag akkor fordult le a binaris, ha a configure script megkapta a --disable-dependency-tracking opciot. Viszont ebben az esetben a kod felet is sikeresen kiolte mikozben semmi de semmi osszefugges nincs az opcio lenyege es az altala kivaltott viselkedes kozott. Kiveve, hogy egy linux pistike elcseszte az egeszet. Igen, tudom, ez nem feltetlen linuxon fejleszto egyedre jellemzo problema, de talan jobban megvilagitja mire probalunk ravilagitani. Az ilyen es ehhez hasonlo esetek _lenyegesen_ sokkal tobbszor fordulnak elo abban az okologiai rendszerben eloallitott szoftverekkel kapcsolatban.

---
pontscho / fresh!mindworkz

Kivancsi lennek, a valgrind-es zabszemteszten atmennenek-e az ilyen projektek.

Mondjuk azon rohogtem, hogy a valgrind szerint meg a OSX STL-jeben is van egy pici memoriaszivargas a iostrem korul, persze ezt mar csak nagyon paranoid modban vette eszre.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"... és azért még el fog tartani egy darabig, mire a különböző Linux disztribekbe bekerül a CLang (vagy akár a PCC), ez azért még odébb van..."

ha erre a PCC-re gondoltál, akkor már nem annyira:)

$ yum info pcc
...
Available Packages
Name : pcc
Arch : i686
Version : 0.9.9
Release : 0.4.100413cvs.fc13
Size : 175 k
Repo : fedora
Summary : The Portable C Compiler
URL : http://pcc.ludd.ltu.se/
License : BSD with advertising and BSD and ISC
Description : The compiler is based on the original Portable C Compiler by Stephen C.
: Johnson, written in the late 70's. Even though much of the compiler has been
: rewritten, some of the basics still remain.
: PCC debuted in Unix Version 7 and replaced the DMR compiler (Dennis Ritchie's
: original C compiler) in both System V and the BSD 4.x releases. Some history
: about pcc is in the A History of UNIX before Berkeley: UNIX Evolution:
: 1975-1984 and in the Evolution of C.
:
: About 50% of the frontend code and 80% of the backend code has been rewritten.
: Most stuff is written by Anders Magnusson, with the exception of the data-flow
: analysis part and the SSA conversion code which is written by Peter A Jonsson,
: and the Mips port that were written as part of a project by undergraduate
: students at Luleå University of Technology (LTU).

A teljesség kedvéért - ahogy alább írták a kollégák, ez lesz majd a Debianban öt év múlva :)

# yum info clang
....
Available Packages
Name : clang
Arch : i686
Version : 2.7
Release : 5.fc13
Size : 3.1 M
Repo : updates
Summary : A C language family front-end for LLVM
URL : http://llvm.org/
License : NCSA
Description : clang: noun
: 1. A loud, resonant, metallic sound.
: 2. The strident call of a crane or goose.
: 3. C-language family front-end toolkit.
:
: The goal of the Clang project is to create a new C, C++, Objective C
: and Objective C++ front-end for the LLVM compiler. Its tools are built
: as libraries and designed to be loosely-coupled and extensible.

Tudom, nem mervado: 


hron@fruitbox ~ $ eix clang
* sys-devel/clang
     Available versions:  ~2.7-r2 ~2.7-r4 **9999 {debug +static-analyzer system-cxx-headers test}
     Homepage:            http://clang.llvm.org/
     Description:         C language family frontend for LLVM

-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( LGee | 2010. 09. 23., cs – 14:04 )

Marginalis problema, de "configure: error: gcc|icc required but not found", tehat szivem csucske (lol), az IBM xlC nem tamogatott.

Én szoktam ARM-ra (kereszt)fordítani CLANG-gal. Nem különösebben bonyolult, sőt, néha ügyesebb kódot gyárt, mint a GCC. Viszi az ARM Cortex-M3-at, M0-t és A8-at is.

A GCC-vel az a bajom, hogy nehéz úgy lefordítani, hogy arm-none-eabi vagy arm-none-linux-gnueabi targetre készítsen futtatható kódot (legalábbis ha szeretnék C++ fordítót is libstdc++-szal).

Röviden összefoglalva: nekem a CLANG/LLVM nagyon szimpatikus (legutóbb tegnap fordítottam SVN-ből).

Fuszenecker Róbert

( log69 | 2010. 09. 26., v – 15:46 )

keresem az infót, de nem találok arról, hogy clang támogatná OpenMP-t vagy egyéb más módon párhuzamosítást thread-ekkel szemben GCC-vel például.

valakinek erről infója?

pthreads miert ne lehetne hasznalhato? Az OpenMP csak syntactic sugar, a hatterben o is pthreadset hasznal GCC-vel vagy MinGW-vel forditva. Az MSVC-nek sajat OpenMP megvalositasa van, ami nem pthreadses, nyilvan. Az OpenMP-vel sokszor vigyazni kell Windows platformon, csak az MSVC-t hasznaljuk. A pthreads ugyanis Win32 alatt erosen bugos, pl. raul egy olyan szalkezelo hivasra, ami miatt mas progik nem nagyon tudnak vele egyuttmukodni. JNI-vel megszivtuk ezt, a JVM nem tudott elindulni sem.

igen az OpenMP direktívákat fordítja le a GCC pthread hívásokra, eddig rendben van, de azért sokkal egyszerűbb programozni és megéri sok esetben, ahol nem, ott egyetértek, még mindig ott a pthread.

azt figyelgettem hogy MingW még nem támogatja. MS visual studio 2005-től viszont Windows-on is elérhető.

köszi, így már beugrott hogy Mac OS Leo-val kapcsolatban olvastam GCD-ről. viszont ilyen szempontból akkor sajnálatos, mivel az OpenMP nagyobb hardver és szoftver gyártók által is támogatott szabvány. meg ahogy hamar gyorsan átfutottam a wiki-t, sokkal kényelmesebben programozhatónak és olvashatóbbnak tűnik az OpenMP kód.