es eljott a nap: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc

As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc.

Hi Everyone,

As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc.

If you are using gcc, you have two options:

1) Install one of the lang/gcc* ports (Warner has been working on separating out the patches to our GCC, so these should soon be patched to provide the same features as the one in base)

2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world.

GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon...

Thanks to Warner for all of his recent work on disentangling the toolchain, to all of the people (Roman, Dimitry, Brooks, and others) who worked on getting clang integrated into FreeBSD and to everyone who tested it and filed bug reports. As of today, PowerPC64 joins x86 and ARM as platforms where world+kernel can be successfully built (and work) with clang (although it isn't the default yet and needs more testing), and hopefully other architectures will follow soon.

Huge thanks to all of the ports people who have spent the last two weeks working on dealing with the fallout from iconv and ensuring that all of the ports work with clang and libc++. I think over the last week, the number of failing / ignored ports has dropped by about a thousand a day on the no-gcc test box that Bapt has been running, which is a phenomenal achievement.

David

http://lists.freebsd.org/pipermail/freebsd-current/2013-September/04431…

Megnéztem a logot. Az elején, az aargb.c fájlban levő warningok teljesen jogosaknak látszanak, és a javítás tényleg annyi, mint ami az üzenetben szerepel, azaz inicializálni kéne azt a három változót az üzenetekben szereplő 339. sorban.
A valódi hiba a hiányzó 2 fv gyors netes keresgélés alapján az OpenMP csomag része. Ja, a fájlok elején látom, hogy direkt van ott az OpenMP. Ebben az esetben - mivel ez FreeBSD-n (sőt szerintem kb sehol) - nem a rendszer része, egyrészt az include -ban kacsacsőr helyett idézőjel, másrészt csomagfüggőségként fel kell venni.

(Eredetileg akartam írni, h az aaphoto szerzője itt a HUPon is fent van emlékeim szerint ahorvath néven, aztán kicsit meglepődtem, szóval akkor döntsd el, h a szerző javítsa, vagy a FreeBSD ports maintainerje. :-) )

Keresgéltem kicsit OpenMP irányba. Azt látom, h GCC-hez van, ezért aztán ott, ahol van valami többé-kevésbé nem elavult GCC, itt van libgomp néven. Ellenben ha a 10-esből épp kidobják a GCC-t a base-ből, akkor épp nem lesz. Az mondjuk számomra nem világos, hogy ha a gcc-t kidobják, akkor az omp.h mondjuk miért maradt benne - vagy legalábbis a fordítókörnyezet miért hiszi, hogy van omp.h. Maybe a bug?

Ezzel csak 2 bajom van.

- ha OpenMP nelkul forditja, akkor ugyan - felteszem - rosszabb lesz a futas ideju teljesitmeny, de cserebe nem rak fel egy boszme nagy GCC-t
- ha jol lattam, akor osszesen arra van hasznalva az OpenMP, hogy lekerdezi, h hany "proci" van a gepben - ebben az esetben az OpenMP hivasa egy db sysctl( hw.ncpu )-ra redukalodik, ezt belehegeszteni vaoszinuleg nem akkora iszonyat macera, cserebe egy boszme GCC nelkul lesz ugyanugy multiprocesszoros teljesitmeny

Nem csak a processzorok számának megállapításához használom OpenMP-t, hanem ciklusok párhuzamosítására. Csak gondolom a "#pragma omp parallel" hivatkozást alapból figyelmen kívül hagyja a clang fordító.

Ez esetben eldöntendő, hogy melyik jobb. Minden magot használni, vagy GCC-t telepíteni.

Gondolom kutya se használja a progim, úgyhogy majdnem teljesen mindegy.

Ja, hogy az omp nem (csak) konkrét rutinokat jelent, hanem pragma-kat is. Akkor már értem. (Azt hittem olyasmi történik, hogy lekérdezed a a proci darabszámot, aztán írtál- mondjuk egy ciklust, ami annyi szálat indít, ahány proci van, és úgy van megírva, h ha nincs OMP, akor egyszálú vagy, ha van, akkor N.)

Hát remélem nem értettelek benneteket félre.
Ime a patch:
===
*** Makefile.orig 2013-09-09 16:49:03.000000000 +0200
--- Makefile 2013-09-09 16:48:37.000000000 +0200
***************
*** 22,27 ****
--- 22,28 ----
LICENSE= GPLv3

USE_AUTOTOOLS= autoheader
+ USE_GCC= any
GNU_CONFIGURE= yes
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
===
Mivel az oldal biztos elszúrja:
===
$ openssl base64 < Makefile.patch
KioqIE1ha2VmaWxlLm9yaWcJMjAxMy0wOS0wOSAxNjo0OTowMy4wMDAwMDAwMDAg
KzAyMDAKLS0tIE1ha2VmaWxlCTIwMTMtMDktMDkgMTY6NDg6MzcuMDAwMDAwMDAw
ICswMjAwCioqKioqKioqKioqKioqKgoqKiogMjIsMjcgKioqKgotLS0gMjIsMjgg
LS0tLQogIExJQ0VOU0U9CUdQTHYzCiAgCiAgVVNFX0FVVE9UT09MUz0JYXV0b2hl
YWRlcgorIFVTRV9HQ0M9CWFueQogIEdOVV9DT05GSUdVUkU9CXllcwogIENQUEZM
QUdTKz0JLUkke0xPQ0FMQkFTRX0vaW5jbHVkZQogIExERkxBR1MrPQktTCR7TE9D
QUxCQVNFfS9saWIK
$
===


begin-base64 644 log69.xz
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4BrRCPddACmYykarec1wWuOyuHWSQFx0n4Zpm+xkTTcg
QiWAM12J/1Fkiu10NjyvtVuUKeQXDasIZOGHtjKThPpPKFa0S+dZ24zy5laJWsMnJzX/mi8ZLcIc
mGx7qJiVEr15mibfQws4uwTu8b2gSme5CPMJKGlzORhhVAFiaEdl5NI9QVuZhjF4te570N+V/oDR
C3xw2oMmgTc9Niiq/IF603553cGS5RK+sGr5W9J45RTaJ481UpgwJZqkmAJE4z46OY7I8IEV2Jmf
QGp8bkp7YrzvQhl1AOr0tmeWA8C6jReTU+i8Te2Rwxy4eh76NorDTVz7kEvnycRvM7QcOmxuokSc
u9srXehXZKa7NJo+gsymlC59gYA+h7rQ03KKVWddxM0jqReffAk/r95cUNXZT6ZGnjYem2O/ZJS0
SEyDrLkoGZ5EalROyZS/hYXS4Dt6A1xc+V7kM8msOpEvZ3Op06dlsAc0S6269v+Nbep5sAvxRgtx
8x5EkfX7MCeePlLYqf4FcKCougN3JW5q+SflORMKkYQLmscGo+9z2lXTjl3R2fn2i/mSIeTpkhiR
mldO/htvJVuXXpIO45mYQMSjpXkh6ZVHjBHCJuJDD3ODmE1CV66xTv3WIKufP8d871S22epQTjT1
cl6mi8icQFb6gX4n5yMKP+GB7h+2e/e9X/q+S1KDQ4JR3M7Bw5iY0VdGanILLmK8tUfha75zACyn
oCvOxjhKZL/AlLx37ZXGlAgOXVoYkmRbZXELY1AOjlfd4gcYtU0YkMJ9NCgJomZO/2rBtyOrIvnn
n5hMU9UiYIgiiwmeWGGQ6ZHMGNHJtjDvMICsFvuBiSZUtG/y52eOEdHcKAdWSqseYxDwRxYrPYG8
OZuKLOHeqFQmug2cNoXwcSX+/O/J13ptqwg9OgPcRfhkygiAGm6GEN1LAqyihAVJabzvKyiaMAAL
0whfhr24XjGp/5sh+TLK83fBGDFEVssKxpuHyn6TIfgc9F2iD5jrbEOB8ArRY4k4kFUj273BdvE5
O6Hi+C0bWkwreUk80KPi35iE900njW5OaWj2S7Rs3lAzP4D8Wr1mqFVI8SgQbG0qzS5N/e2gOZGj
Vxs8kQaamqUpHkydJ+K5myIawQOU6Zd9FtFNfZD1Ha48jNhWjGY3BM3qMDHs3enIJlusUiDGOWcj
6DvHOXEPK6a8ddMibcbgDSGVc+tnJsuErIZnusrNaGD1H64ILk181VFGs6GZNxF9NmYQ7h/MRbT9
88cQliAvHqYgGI6Ov15OpVa533wmvZG7hsGEEyrfUbaEKDlePSVTtQfwXQneYg5QLLQhWrIY3e60
FySZ8STebDnsVS6DLVSsWWvPQpt2X/R7Q8W8szeLmLBHT/Wyd9tld1l2QujK053TL+1KFC7p9lBH
HgfVM5oPqac9Gzp8nnSYLvuB7/TUnaImPkEizvHvUmeWiovkdSR2yu24k+x0migj+pp2lm6Ip++a
UaIj8l4s6IF1hcX1ogffT11FHdrCYZ7tPGIMY39p4jpcESKqcrxvT+KFmTNwLSpAkXJWdsB8SiOA
zhnLgcItw9HAlbpsn55nSuCBwvSydiEWShxYGnA9il0JC2Jfg4Oy2fOywQGuVTcAswqK48Iu4qFP
/ZZWrYmsmnS/yVtJFDgVetQE7r+dcVJxom748+sZzdmmqzxmC3pv09uZqUuMJE3aauzdhfpIkJxx
DBZwM8YZQG/FtHM9SlV8ib9UsL8C5uPDPrFEkCwJPIMqzXhf1ZP3cfZIRijDrt3clBQ7hSM38OTM
ntYQ3M93WJ6H1S07mMsR/rNMxTofYVmOV/jEI8aVEA9MRiBDl7tgCHR38L0ByZ6auyFeHTJ4/wYl
ghflZ15oCcdSvAISmSzBrIgyhOWSDwxKK5YkPoI/X6zJwyTPtjRd9w+BJvheQRLo9NYRVF2+xBIt
VQY5MM9icPHVmsYLSycOsdBlr8Kl/lP1+ZanE1uZkF2H4ay0Tb4FnDCoi31gn+RD1Gv5Xi9WUBcs
qdgcAoK2IArK1wGsEJY3kb2tpBUlh62WyreSecXp3gp4D1BCopgGXftfrwfV/WxBOJl6i2DcCuhZ
2vBvIO/NjNZDhmZY0Vf+O9k4cJo67IwWCBSyGa7xyjUk9Gx+h35h/S7j+5sEaW5ZnpAcXIIBMnAi
Xm/9eEr5U1ix8DgmFWLNFwUILlELCT4vJb9Y0EF+3cHE8QdBxkLHeEvxYgx2B/oM9kgi7Fjo00ID
wQkkqqJgu+ttmAQh+vBXeLlgBrb9o9XQuzQEiq1ruepzQoQFfowxl5GQ4+zCsSh3jbas1lchDclj
cTQ7VjSmS9BDXf7MDPx1fbrIqTzo4REBuCigvfYQFFzae7Jty9uIEG+pH8m7qwub9DItUct5I2XQ
QHEY4FxOJ4o16S00XTqabH3B30Td7mKeGXgPudV28cxPVh5Rio9wwfz83uWyQGagtvZ05JNPU3zG
2xtpZ+mHwYv25WMNHJD+tmgWLzROwu/sVbgtgCzQO3xNMtJCalJ85Ap2tgYlWj9FmjTaHzb9byZ2
xIG3As7SzCCi5bB6Qu0z+TCix50nyXC5J/v/FaE2CbrUqdJw6pIsOOHuMJ9ihNCAmcyjDzmMKMWj
W0SoWBlATof2RWT5euuo4qDmOjWjRHjX0adQmYywGt7bBkM0BCmGebfFEQ1nlEgGwpk7Ua7ZoQ7N
yaOBw4x6c6nIqAmrXPoH32Js97gdSLbuH6fuFUTpRoKkzsFOwIhT2NDEi5U/SpStHorhCMKbnyd9
W4caxZs2D/mCNYfrpEPN0NoXne3ejeEKSfG8f3Oq7WW+AdfzkIcfdWANd56n1+41B+Ed6YqYYHRU
P/c13u4nZhWEpVaEJJiaeVOjyKOX1/+FCnlbplf3aqa/bu7/X1p7QPv1rZx6nZIRLF0erHBBBYEc
2bNphyUH0469WCuSkRDKrBJPp/gRoufzvUDRTyJtucAgnRZhE1IU2HO7XcTQLUoLWNWuhxR1s0vI
w6nMvJNew3+mLBAbAnzXWPQwWNhJgFzJN63fjySGKTh6nbJ/tlDiMkAO7tTUAAAAJaOJgVJL4sIA
AZMS0jUAALsieuyxxGf7AgAAAAAEWVo=
====

Kösz, ezt be fogom küldeni pr-hez. Inkább ez a megoldás jobb szerintem, mert lehet más progiknak is GCC függősége, azért gondolom van 20 30 ezer csomag a ports fában, ha meg nagy a valószínűsége hogy lesz GCC a rendszeren, ez optimálisabb megoldásnak tűnik. Lévén egy pontos feature veszne el ez által.

De úgyis csak annak és akkor érdekes, aki és ha egyáltalán használja a progim.

Úgy döntöttem hogy hozzáigazítom a rendszerhez az ő elképzelésük szerint.

Gondolom nem csak az én cuccom használ OpenMP-t. Ha annyira fontos a FBSD projektnek a Clang, hát akkor történjen a fordítás azzal. Aki meg úgy gondolja, az alapértelmezetté teszi a GCC-t. Gondolom FBSD userek inkább azt fogják preferálni, ha nem rántja be a cuccom a GCC-t ha nem muszáj.

Egy olyat kellene még beletennem, hogy ha cc == gcc akkor is használjam az openmp-t.

Szerinted ez helyett

.if (${ARCH} == "amd64" || ${ARCH} == "i386") && ${OSVERSION} >= 700000 && ${OSVERSION} < 1000000

ez megfelelő lenne a GCC alapértelmezésének vizsgálatához?

.if (${ARCH} == "amd64" || ${ARCH} == "i386") && ${CC} == "gcc"

CFLAGS+= -fopenmp -D__OPENMP__
.endif

Szerk.: látom ez nem lenne jó, mert ahogy nézegetem neten, CC változó gcc42 vagy gcc 47 meg hasonló értékkel bír gcc esetén.

Akkor azt lenne jó megtudnom, hogy mi a helyes javasolt módja FBSD-n, hogy leellenőrizzem azt a Makefile-ben, hogy GCC-e az alapértelmezett fordító?

Ez lesz a legjobb megoldás, mert így az elérhető megoldások közül az optimálisat kapja a user.

Nem tudnád megnézni nekem hogy mi a CC shell változó értéke 9-es rendszeren?

Szerk.: közben meg kellett néznem, hogy OpenMP GCC 4.2-estől van csak, tehát azt kellene ellenőriznem, hogy gcc v4.2+ az alapértelmezett-e. grep-pelem a ports fában található Makefile-okat, és ilyeneket találtam:

.if empty(CC:T:Mgcc4*)

.if ${CC} != "gcc"

.if ${PORT_OPTIONS:MGCC4}

Ez utóbbinál vajon működhet az MGCC42-vel?

9-esen a GCC a standard, ráadásul kb ezer éve a 4.2.1-s GCC van az alapoprendszerben. Továbbmegyek, tudtommal mindegyik ma még támogatott rendszerben (azaz a 8.x-ben is). Speciel shell-beli CC változó nincs (legalábbis ha jól értettem a kérdésedet, mert echo $CC -vel teszteltem). Mivel az a tippem, hogy inkább make-beli CC-változóra gondoltál, ezt is csináltam:

$ cat Makefile
.default:
@echo CC is ${CC}
$ make
CC is cc
$

No most neked ezzel az lesz a bajod, hogy tudtommal clang-ra váltás után az van, hogy a [mM]akefile-ban szereplő CC az változatlanul cc lesz, csak épp a cc az nem a gcc, hanem a clang binárist jelenti. Most direkt rábutultam a 10.0-ALPHA4-es telepítődiszkre, és ugyanaz a kód pont ugyanazt az eredményt adja. Persze ha elindítom a cc binárist (mondjuk --version opcióval), akkor szépen látszik, hogy ő már ne ugyanaz.
Viszont találtam neked egy érdekes levelet: ebben pont azt írják, hogy mi módon lehetne egyszerűen ellenőrizni hogy gcc vagy clang és ettől függően átadni valami opciókat. Ráadásul megnéztem a buglistát, és commitolták ezt a peccset, szóval jónak tűnik. Az én értelmezésem szerint ez van a peccsben: ellenőrizzük, hogy mit ad ki a cc --version, és ha nincs benne a clang szócska, akkor a CFLAGS változóhoz hozzátesz valamit. No most ha jól gondolom, neked is pont ilyen kellene. Hm?

Ez ránézésre nekem megfelelne.

Írtam egyébként a fórumra meg a levlistára is, még megvárom mit írnak oda, mert szeretnék standard jó megoldást adni a dologra. Ha nem lesz eredmény, akkor megcsinálom mert többet nem érdemel a dolog.

Egyébként meg bevezethettek volna egy nyomorult változót a Clang alapértelmezetté tételével, ha már ennyire fontos nekik.

Illetve itt sem látok semmi erre vonatkozó infót:
https://wiki.freebsd.org/BuildingFreeBSDWithClang

Szerintem ha a buildworld idejét szeretnénk csökkenteni, akkor az igazán jó megoldás a CC_IS_PCC bevezetése lenne. A PCC sok-sok nagyságrenddel kisebb kódméretben, mint akár a GCC, akár az LLVM/Clang. Tehát kisebb diszkhelyigény, jó eséllyel kevesebb memória kell a fordításhoz. És a sokkal kisebb kód sokkal egyszerűbb is, tehát a buildworld közbeni C-fordító előállítása sokkal-sokkal gyorsabb. A PCC sok-sok nagyságrenddel gyorsabban fordít. Akár a GCC-hez, akár a Clang-hoz hasonlítjuk, mérföldeket ráver. Tehát nem csak magának az infrastruktúrának a felépítése, hanem az egész rendszernek a lefordítási ideje is rövidül.
A nagyon sok pozitívum mellett alig egyetlen (maximum két, no jó három) negatívumot tudnék felhozni: vagy elhasal a buildworld az első 3 percben, vagy ha valami csoda folytán végigmegy, akkor működésképtelen lesz a rendszer - de ha ez sem, irgalmatlanul gyengébb lenne a PCC-ben hiányzó optimalizálás miatt. :-)