GCC FreeBSD 10-en

FreeBSD-all

Látom, hogy GCC is no longer built as part of the base system. És tényleg, a frissen telepített rendszeremen nincs gcc, g++, stb. Kérdésem, hogy van-e vagy lesz-e valami bináris csomag, amiből ezek telepíthetők. Találtam ugyan egy gcc nevű csomagot, de az hiányos, ráadásul valami félreeső helyre teszi a fájljait, szóval messze a használhatótól.

  • 7111 megtekintés

( Zahy v | 2014. 01. 15., sze – 13:14 )

A portsban levő GCC-k továbbra is elérhetőek lesznek, és amiből lehet, abból csomag is lesz.

Hát akkor kénytelen vagyok beleásni magam a clang-ba. Kösz.
--
ulysses.co.hu

Szerk:

No, nagyjából meg is van.

Először is: nem gcc-vel kell fordítani, hanem cc-vel. Utána kiderül, hogy a -O6 opció sok neki, elkezdtem egyesével visszavenni, -O4-nél működni kezdett.

Akkor kiderült, hogy a generált objectek formátumát a linker (ld) nem ismeri. Basszus, mégiscsak el kell olvasni a man-t, sóhajtottam egyet, hozzákezdtem. Az első oldalon kiderült, hogy -O4-re olyan kódot generál, amit a (spéci) új linker optimalizálna, azért nem ismeri az ld a formátumot. Tehát tovább visszavenni az optimalizálásból -O2-re. Ezzel már a linkelés is megy az eredeti ld-vel.

Ennyi. Van egy-két új warning, azokat meg kell nézni. Amúgy ebben a projektben 650 darab object fájl van (34 so, 120 exe), kellemetlen lett volna, ha teljesen új build rendszert kellett volna csinálni.

Elvileg -O3-ig jo vagy sima ld-vel is, felette gold kell.

man src.conf:


WITH_GCC
Set to build and install gcc and g++.

It is a default setting on arm/armeb, ia64/ia64, mips/mipsel,
mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, pc98/i386,
powerpc/powerpc, powerpc/powerpc64 and sparc64/sparc64.

# echo "WITH_GCC=" >> /etc/src.conf && make buildworld && ...

vagy ports-bol felrakod a megfelelo gcc-t 


op@pandora-d /tmp> cc -O4 -c test1.c
op@pandora-d /tmp> file tes
test1.c  test1.h  test1.o  test2.c  test2.o  
op@pandora-d /tmp> file test1.o
test1.o: LLVM bitcode
op@pandora-d /tmp> cc -O3 -c test1.c
op@pandora-d /tmp> file test1.o
test1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
op@pandora-d /tmp> cc -O3 -c test2.c
op@pandora-d /tmp> ld -L /usr/lib -lc /usr/lib/crt{1,i}.o test2.o test1.o /usr/lib/crt{end,n}.o

( mrev | 2014. 02. 09., v – 16:24 )

Az előző postomban írtam, hogy végül is megbarátkoztan a clanggal. Most viszont mit látok: 


# pkg install  openjdk
Updating repository catalogue
The following 6 packages will be installed:

        Installing compat9x-amd64: 9.2.902000.201310
        Installing gcc: 4.6.4
        Installing javavmwrapper: 2.4_3
        Installing java-zoneinfo: 2013.i
        Installing alsa-lib: 1.0.27.2_1
        Installing openjdk: 7.25.15_2,1

The installation will require 726 MB more space

138 MB to be downloaded

Proceed with installing packages [y/N]: n

Vagyis az openjdk behozná függőségként a gcc-t.
--
ulysses.co.hu

( fimikz | 2014. 02. 10., h – 09:20 )

Tapasztalataim szerint magas -O flagek nem mindig kifizetodoek. Compiler mindenfele dolgokat csinal, amiktol aztan nehezen debugolhato lesz a dolog, hogyha odakerul. Arrol nem is beszelve, hogy a nyert performancia gyakran alig merheto.

A gold erdekes dolog egyebkent, en sajnalom, h a base-ben levo linker alapbol nem supportalja (plugin kell neki hozza). A feature pontos neve LTO, Link Time Optimization. Annyit csinal, hogy egy LLVM bitcode objectfile-t general a compiler, es linktime-ban tortenik meg egy analizis a teljes, global kodra. Egyik pelda, ha van olyan codepath a tobb object kozott, ami egyaltalan nincs hasznalva, akkor kidobja. Tehat a teljes binaris elemzi, es az alapjan optimizal, nem csak az objectfile-okat lokalisan.

Egyebkent en szemely szerint nagyon megszerettem a clangot, nagyon jo vele fejlesztni. A hibauzenetei nagyon hasznosak; pontosak es lenyegretoroek, es a tippjei is nagyon jok. Es amellett tamogatja az uj szabvanyokat is eleg jol (pl c++11), ellentetben a regi base-ben levo GCC-vel.

Egyebkent a system CC-t az ember mindig "cc"-vel hivta, semmi sem garantalja neked, hogy ezt a funkciot X implementacio biztositja. Ez picit olyasmi, hogy nem mindenhol a bash a /bin/sh ...

Egyetértek.

A bash-sel kapcsolatban: 20 éve úgy kezdődik minden scriptem, hogy '#!/bin/bash'. Sok ilyen script van, nehéz volna mindet megtalálni. Namost vannak rendszerek, amikben magától nincs bash, vagy ha van is, máshol. Ilyen helyeken a konfigurációt azzal kezdem, hogy telepítem a bash-t, felveszem az /etc/shells-be, és átmásolok belőle egy példányt /bin-be.
--
ulysses.co.hu

> Egyebkent en szemely szerint nagyon megszerettem a clangot, nagyon jo vele fejlesztni.
+1

Csak egy hatranya van: elkezdtem nem erteni a GCC-s hibauzeneteket :D
Valamint ilyesmik is leteznek: http://valloric.github.io/YouCompleteMe/, ami sokat segithet.

CI-toolban bent van a clang-os build is (bar release-be nem az megy ki (meg :)). Mar hozott ki hibakat, amiket a GCC szo nelkul megevett.