Το νήμα του Gentoo, version 1.0

[imitheos]

Με το LTO δεν αυξάνεται (και κατά πόσο περίπου) ο χρόνος μεταγλώττισης;

Δεν θυμάμαι σε ποιον gcc έγινε η αλλαγή (νομίζω στον 5άρη) αλλά παλαιότερα η μανίσια επιλογή ήταν τα fat-lto-objects ώστε να είναι πιο εύκολη η μετάβαση. Το fat έγκειται στο γεγονός ότι το αρχείο περιείχε και το κανονικό object file και την αναπαράσταση που χρειάζεται για το lto. Έτσι ο χρόνος ήταν τουλάχιστον ο διπλός και πολλές φορές έφτανε τις 3-4x (αν και όλοι επέλεγαν no-fat-lto-objects).

Με την χρήση των "lite" αρχείων ο χρόνος δεν είναι πολύ αυξημένος. Η περισσότερη δουλειά στον gcc γίνεται στην μείωση της κατανάλωσης της μνήμης όπως είπε και ο petran. Αν δεις το blog ενός dev που ασχολείται με αυτό το τμήμα του gcc, το libreoffice για χτίσιμο με -j16 ήθελε 16GB με τον 4άρη, μετά 12GB με τον 5άρη και τέλος 10GB με τον 6άρη (δεν θυμάμαι ακριβώς τα νούμερα αλλά η τάξη μεγέθους ήταν αυτή).

Ένα γρήγορο τεστ που έκανα τώρα είναι ffmpeg-3.3 χτίσιμο με LTO = 2:09.98 και χτίσιμο χωρίς LTO = 1:51.15 δηλαδή 20 δευτερόλεπτα παραπάνω. Αν κοιτάξεις μόνο ποσοστά, σε πολλά προγράμματα ο χρόνος μπορεί να αυξηθεί δραματικά ακόμη και 200% αλλά πρακτικά πηγαίνει από τα 4 δευτερόλεπτα χτίσιμο στα 7 δευτερόλεπτα.

Τελευταία φορά που έκανα μετρήσεις (σε Slackware) υπήρχαν κάποια προγράμματα που συμπεριφέρονταν τρελά όπως

cmake        3:33 -> 8:27
virtuoso-ose 2:11 -> 10:21
NetworkManager  2:54 -> 6:48
samba       12:12 -> 28:44
mesa        10:08 -> 21:44

Ίσως είχα κάνει κάποια βλακεία εγώ όμως. Αύριο θα δοκιμάσω να χτίσω τα συγκεκριμένα με/χωρίς LTO και να συγκρίνω χρόνους. Την mesa για παράδειγμα σήμερα που έχτισα την 17.0.4 πήρε μόλις 12:14 και όχι τόσο εξωφρενικό χρόνο των 21 λεπτών.

Επίσης το LTO είναι κρίμα να το ανοίξει κανείς, να φάει το reemerge για πόσες μέρες και στο τέλος 5 - 10 βιβλιοθήκες που δεν το σηκώνουν, να επηρεάζουν και να προκαλούν compilation linking failure σε όσα πακέτα πατάνε σε αυτές. Ίσως με τον 7άρη από του χρόνου να του ξαναδώσω ευκαιρία.

Αυτό που περιγράφεις να επιτυγχάνει το linking μιας βιβλιοθήκης και μετά να αποτυγχάνει κάτι που την χρησιμοποιεί ώστε να χάνεις πάρα πολύ χρόνο είναι σχετικά σπάνιο. Οι μόνες περιπτώσεις που θυμάμαι να γίνεται αυτό είναι με ένα συστατικό του qt (το οποίο διορθώθηκε σε επόμενη έκδοση) και με την gnu-efi η οποία επιτυγχάνει αλλά μετά δεν μπορείς να κάνεις compile τον elilo.

Εδώ που είμαι τώρα:

% find /var/db/pkg -mindepth 2 -type d|grep -v virtual|wc -l 
835            

% cat /etc/portage/package.env 
app-cdr/cdrtools nolto.conf
dev-lang/perl nolto.conf
dev-lang/spidermonkey nolto.conf
dev-libs/elfutils nolto.conf
dev-libs/libgcrypt nolto.conf
dev-util/perf nolto.conf
dev-util/valgrind nolto.conf
media-libs/alsa-lib nolto.conf
media-libs/avidemux-core nolto.conf
media-libs/x264 nolto.conf
net-misc/dhcp nolto.conf
sys-apps/man-db nolto.conf
sys-apps/pciutils nolto.conf
sys-fs/xfsprogs nolto.conf
x11-base/xorg-server nolto.conf
x11-drivers/xf86-video-intel nolto.conf

Μερικοί genti έχουν πολύ μακριές λίστες με προγράμματα που έχουν πρόβλημα αλλά συνήθως είναι LTO σε συνδυασμό με graphite που εκεί όντως θέλει λίγο δουλειά ακόμη. Από ό,τι διαβάζω το graphite οδηγεί σε τρομερές αυξήσεις σε ταχύτητα αλλά έχει τέτοια θέματα ειδικά σε συνδυασμό με LTO. Το σκέτο LTO που χρησιμοποιώ εγώ δεν έχει και τόσα θέματα.

Αξίζει ημίθεε το hardened για desktop χρήση; Εννοώ θα έχω πρόβλημα να τρέχω κάποια system tools/εφαρμογές ή ανεβαίνει ο χρόνος του compile;

Αν αξίζει εσύ πρέπει να το κρίνεις Πρόβλημα δεν θυμάμαι να έχω αντιμετωπίσει. Θυμάμαι ότι το skype είναι masked στο hardened προφίλ επειδή δεν παίζει λένε αλλά δεν το δοκίμασα χειροκίνητα να δω. Γιατί να μην παίζει δηλαδή ?

[GoofyX]

Οκ, οπότε η επόμενη ερώτηση είναι πώς ενεργοποιείς το lto στον GCC; Από ότι βλέπω έχει παράμετρο (θα μπορούσε να μπει στο CFLAGS δηλαδή), όντως μπαίνει έτσι;

[petran_18]

@imitheos Αναφερόμουν σε πακέτα που δεν περνάνε το compilation με lto και αρα και οσα λινκάρονται με αυτά πρεπει να μπουν (επίσης) στο package.env, κάνοντας μεγάλη την λίστα με τα εξαιρούμενα πακέτα. Τεσπα, κουβέντα να γίνεται

Btw, το graphite δεν είναι για συγκεκριμένα πακέτα; Γενικά από οσο θυμάμαι είναι βαρβάτη και βάρβαρη βελτιστοποίηση, που χρήζει ιδιαίτερης μέριμνας και προσοχής στο σύστημα.

Όσο και οι compilers, ωστόσο, βελτιώνονται και ωριμάζουν, τόσο και μια σοβαρή source based διανομή μπορεί να επωφελείται

- - - Updated - - -

@goofyx Η cflag είναι το μονο εύκολο. Καλο θα ειναι να ριξεις μια καλή ματιά στο documentation του gcc για το -flto και τα συναφή. Αξίζει να ξέρεις κάτι παραπάνω από τον 'διακόπτη'.

Επίσης -ας με διορθώσει κάποιος σχετικότερος- ήθελε επέμβαση και στα ldflags - το λεει και η λέξη : link time optimization.

Πάντως, ναι έτσι μπαίνει. Με το -flto και ίσως κάποια -flto-xxx. Επιφυλάσομαι για την ldflag και ένα symlink του gold linker. Δεν είμαι σε πισι, αν γκουγκλάρεις ή περιμένεις αύριο το πρωί, οι απαντήσεις θα είναι σαφέστερες

- - - Updated - - -

-flto=x -fuse-linker-plugin στο cflags και ${cflags} κάτω στο LDFLAGS.

Δες εδώ για το symlink btw.
http://gcc.1065356.n8.nabble.com/LTO...td1232481.html

Γράφω απο κινητό, συγνώμη αν δεν φαίνεται κάτι σωστά.

[imitheos]

# genlop -t cmake
 * dev-util/cmake

     Wed Apr 19 11:15:02 2017 >>> dev-util/cmake-3.7.2
       merge time: 1 minute and 54 seconds.

     Wed Apr 19 11:19:38 2017 >>> dev-util/cmake-3.7.2
       merge time: 3 minutes and 17 seconds.

Η διαφορά είναι όντως μεγάλη στο συγκεκριμένο αλλά όχι όσο είχα βρει πριν.

Τεστ για ffmpeg:

# genlop -t ffmpeg
 * media-video/ffmpeg

     Wed Apr 19 11:25:30 2017 >>> media-video/ffmpeg-3.3
       merge time: 2 minutes and 25 seconds.

     Wed Apr 19 11:48:38 2017 >>> media-video/ffmpeg-3.3
       merge time: 3 minutes and 3 seconds.

# find . -name "*.a" -size +50M -exec du -h {} \; 
84M	./lto/libavcodec/libavcodec.a
101M	./nolto/libavcodec/libavcodec.a

% /usr/bin/time ffmpeg -i 218-Senile\ Lines.mkv -target pal-dvd -b:v 2000k -b:a 192k -aspect 16:9 tmp.vob -y
263.93user 3.84system 2:41.47elapsed 165%CPU

% /usr/bin/time ffmpeg -i 218-Senile\ Lines.mkv -target pal-dvd -b:v 2000k -b:a 192k -aspect 16:9 tmp.vob -y
262.74user 3.99system 2:26.19elapsed 169%CPU

Αυξάνεται ο χρόνος χτισίματος αλλά ο compiler μπορεί να κάνει καλύτερη επιλογή στις βελτιστοποιήσεις και να παράγει καλύτερο κώδικα με αποτέλεσμα (ίσως υπό συνθήκες) βελτίωση των επιδόσεων. Το συγκεκριμένο video ήταν το κλασικό επεισόδιο σειράς 40 λεπτών και μετατράπηκε από h264/aac σε mpeg2/ac3 με ακριβώς την ίδια εντολή (αφού καθαρίστηκαν όλα τα buffers φυσικά).

Οκ, οπότε η επόμενη ερώτηση είναι πώς ενεργοποιείς το lto στον GCC; Από ότι βλέπω έχει παράμετρο (θα μπορούσε να μπει στο CFLAGS δηλαδή), όντως μπαίνει έτσι;

@goofyx Η cflag είναι το μονο εύκολο. Καλο θα ειναι να ριξεις μια καλή ματιά στο documentation του gcc για το -flto και τα συναφή. Αξίζει να ξέρεις κάτι παραπάνω από τον 'διακόπτη'.

Επίσης -ας με διορθώσει κάποιος σχετικότερος- ήθελε επέμβαση και στα ldflags - το λεει και η λέξη : link time optimization.

Πάντως, ναι έτσι μπαίνει. Με το -flto και ίσως κάποια -flto-xxx. Επιφυλάσομαι για την ldflag και ένα symlink του gold linker. Δεν είμαι σε πισι, αν γκουγκλάρεις ή περιμένεις αύριο το πρωί, οι απαντήσεις θα είναι σαφέστερες

- - - Updated - - -

-flto=x -fuse-linker-plugin στο cflags και ${cflags} κάτω στο LDFLAGS.

Δες εδώ για το symlink btw.
http://gcc.1065356.n8.nabble.com/LTO...td1232481.html

Γράφω απο κινητό, συγνώμη αν δεν φαίνεται κάτι σωστά.

Σε πολλούς οδηγούς δίνονται CFLAGS που είναι ένα μακρυνάρι μια ώρα αλλά οι περισσότερες παράμετροι δεν χρειάζονται πλέον. To fno-fat-lto-objects είναι ενεργοποιημένο από ένα gcc και πέρα. Το fuse-linker-plugin είναι ενεργοποιημένο αν τα binutils έχουν υποστήριξη για plugin και ο gcc χτιστεί με υποστήριξη για lto (και τα δύο ισχύουν εδώ και πολύ καιρό) και πάει λέγοντας. Αυτό που έχω εγώ είναι -flto σε CFLAGS/CXXFLAGS/LDFLAGS και το symlink που έγραψε ο petran.

Θεωρητικά το μόνο που χρειάζεται είναι το flto στην CFLAGS. Τα υπόλοιπα είναι workarounds για κάποια προγράμματα.

1) Κάποια makefiles είναι έτσι γραμμένα ώστε δεν περνάνε τις CFLAGS κατά το linking (δηλαδή δεν έχουν LDFLAGS="blah blah ${CFLAGS}" όπως έχουν τα περισσότερα) οπότε βάζεις -flto και στην LDFLAGS
2) Όσα προγράμματα δημιουργούν στατικές βιβλιοθήκες με το ar ή χρησιμοποιούν το nm, αυτά δεν παίζουν γιατί δεν μιλάνε "lto" οπότε ή πρέπει να ορίσεις και AR=gcc-ar όπως το link που έδωσε ο petran ή πρέπει να ορίσεις την lto βιβλιοθήκη του gcc ως plugin στις binutils. Είχα διαβάσει ότι το gcc-config θα αλλαχθεί ώστε να το κάνει αυτόματα αλλά για την ώρα το κάνεις symlink εσύ.
3) Αν το makefile δεν χρησιμοποιεί τον gcc για το linking αλλά χρησιμοποιεί κατευθείαν ld τότε δεν παίζει γενικά.

Edit: Ξέχασα να γράψω δύο πράγματα:
1) Δεν μπορείς να έχεις debugging symbols σε συνδυασμό με LTO. Γίνεται δουλειά συνέχεια για να βελτιωθεί η κατάσταση αλλά για την ώρα δεν μπορείς να έχεις -g στον compiler.
2) Φυσικά μπορείς να χρησιμοποιήσεις και τον clang αλλά εκεί είναι λίγο περισσότερα τα προγράμματα που δεν γίνονται compile με LTO. Φυσικά όπως και στον GCC, σε κάθε έκδοση του llvm η κατάσταση βελτιώνεται.

% grep lto /etc/portage/make.conf 
CFLAGS="-march=haswell -mabm -O2 -pipe -flto"
LDFLAGS="-Wl,-O2 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-z,now -Wl,-z,relro -flto=4"

% cat /etc/portage/package.env 
app-cdr/cdrtools nolto.conf
dev-lang/perl nolto.conf
blah blah ίδιο με πριν

% cat /etc/portage/env/nolto.conf 
CFLAGS="${CFLAGS} -fno-lto"
CXXFLAGS="${CXXFLAGS} -fno-lto"
LDFLAGS="${LDFLAGS} -fno-lto"

Αυτά αν θέλει κάποιος να το δοκιμάσει. Στα περισσότερα προγράμματα δεν θα κερδίσεις τίποτα. Καλύτερες επιδόσεις ίσως δεις σε τεράστια προγράμματα τύπου ffmpeg, libreoffice, firefox.

[petran_18]

Προσπαθώ να ανοίξω νήμα για το LTO και βγάζει error το forum. Τέσπα, κάπως έτσι είναι όντως τα πράγματα.

1)

# ln -sfv /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so /usr/lib/bfd-plugins/
'/usr/lib/bfd-plugins/liblto_plugin.so' -> '/usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so'

ή

# ln -fvs /usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so.0.0.0 /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins
'/usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/liblto_plugin.so.0.0.0' -> '/usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/liblto_plugin.so.0.0.0'

2) -flto (και ίσως -flto-report για verbosity) στα cflags και ldflags - δεν είμαι σίγουρος για αυτό αλλά δε θα σκάσει ο ld.

Αν δούμε "ar: xxx.o: plugin needed to handle lto object", τότε το lto plugin δεν φορτώθηκε σωστά και άσχετα αν το compilation πετύχει, ο linker δε θα έχει εφαρμόσει Link Time Optimizations.

[petran_18]

Θέλω να περάσω configuration options σε qmake configured πακέτο και μετά λύπης μου διαπίστωσα ότι το EXTRA_ECONF, δουλεύει μόνο σε autotools based.

Ξέρει κανείς άλλον τρόπο εκτός από patch κάτω από το /etc/portage/patches/category/package ?

[imitheos]

Θέλω να περάσω configuration options σε qmake configured πακέτο και μετά λύπης μου διαπίστωσα ότι το EXTRA_ECONF, δουλεύει μόνο σε autotools based.

Ξέρει κανείς άλλον τρόπο εκτός από patch κάτω από το /etc/portage/patches/category/package ?

Δεν είναι δόκιμη λύση φυσικά αλλά μια μπακάλικη λύση, μέχρι να σου απαντήσει κάποιος πιο γνώστης, είναι να πας στο ebuild και εκεί που λέει eqmake5 να προσθέσεις τα options που θέλεις.

[petran_18]

Δεν είναι δόκιμη λύση φυσικά αλλά μια μπακάλικη λύση, μέχρι να σου απαντήσει κάποιος πιο γνώστης, είναι να πας στο ebuild και εκεί που λέει eqmake5 να προσθέσεις τα options που θέλεις.

Ήταν το πρώτο που σκέφτηκα ημίθεε. Ωστόσο θα πρέπει ή

α) τα ebuild όλης της Qt5 να πάνε σε overlay (εντάξει δεν έχει τραγικό overhead)
ή
β) να κάνω edit μέσα στο tree και git stash κάθε φορά που τραβάω αλλαγές στο tree - ακριβώς για να μπορώ να τις τραβάω χωρίς conflicts.

Mια variable τύπου extra_econf στο package.env θα ήταν πολύ νοικοκυρεμένη λύση αλλά προς το παρών το λύνω με patch στο configure (μπλιάχ). Αμαρτία, τέτοιο customizability και δες που σκόνταψε...
Σε ευχαριστώ όμως για τον χρόνο σου

[imitheos]

Ήταν το πρώτο που σκέφτηκα ημίθεε. Ωστόσο θα πρέπει ή

α) τα ebuild όλης της Qt5 να πάνε σε overlay (εντάξει δεν έχει τραγικό overhead)
ή
β) να κάνω edit μέσα στο tree και git stash κάθε φορά που τραβάω αλλαγές στο tree - ακριβώς για να μπορώ να τις τραβάω χωρίς conflicts.

Mια variable τύπου extra_econf στο package.env θα ήταν πολύ νοικοκυρεμένη λύση αλλά προς το παρών το λύνω με patch στο configure (μπλιάχ). Αμαρτία, τέτοιο customizability και δες που σκόνταψε...
Σε ευχαριστώ όμως για τον χρόνο σου

Ίσως υπάρχει κάποια παράμετρος απλά να μην είναι και τόσο γνωστή. Αν όχι, ζήτησε το μήπως μπορεί να μπει στο επόμενο eapi.

Εμένα ένα πράγμα που με νευρίαζε ήταν ότι το epatch_user ή όπως λεγόταν έπρεπε να δηλωθεί μέσα στο ebuild για να μπορείς εσύ να έχεις custom patches. Και όπως καταλαβαίνεις, ζήτημα 50 ebuilds να είχανε πρόνοια μέσα να τρέξουν την συνάρτηση. Πολύς κόσμος το ζήτησε να μπει γενικά και έτσι στο eapi 6 μπήκε να τρέχει από την μάνα του χωρίς να δηλώνεται μέσα στο ebuild οπότε τώρα μπορούμε να έχουμε custom patches σε όλα τα ebuilds.

[petran_18]

Ίσως υπάρχει κάποια παράμετρος απλά να μην είναι και τόσο γνωστή. Αν όχι, ζήτησε το μήπως μπορεί να μπει στο επόμενο eapi.

Εμένα ένα πράγμα που με νευρίαζε ήταν ότι το epatch_user ή όπως λεγόταν έπρεπε να δηλωθεί μέσα στο ebuild για να μπορείς εσύ να έχεις custom patches. Και όπως καταλαβαίνεις, ζήτημα 50 ebuilds να είχανε πρόνοια μέσα να τρέξουν την συνάρτηση. Πολύς κόσμος το ζήτησε να μπει γενικά και έτσι στο eapi 6 μπήκε να τρέχει από την μάνα του χωρίς να δηλώνεται μέσα στο ebuild οπότε τώρα μπορούμε να έχουμε custom patches σε όλα τα ebuilds.

Το ζυγίζω να ανοίξω ένα bug report - πρώτα πρέπει να ρωτήσω στο irc ή το επίσημο forum.

Για αυτό που λες με τα custom patches, εγώ εβαλα ένα hook μέσα στο global bashrc του portage, γιατί το x264 (που ήθελα να πατσάρω) δεν πατάει στο EAPI 6. Επίσης άλλο φάουλ είναι η ανύπαρκτη τεκμηρίωση γύρω από τα bashrc. Ίσως με ένα hook να μπορούσα να κάνω override τα myconf / qt5-build_src_configure για 5 συγκεκριμένα ebuilds - ίσως και όχι δεν γνωρίζω. Ούτε patch, ούτε πόσα symlinks κάτω από το /etc/portage/patches και άντε πάλι για κάθε package upgrade.

Η γκρίνια της ημέρας

[GoofyX]

Ένα σωρό πακέτα θέλουν rebuild μετά την αναβάθμιση του gcc στον 5.4.0... Πας να ξεκινήσεις κάτι ή να το κάνεις build και βλέπεις σου χτυπάει σε κάτι εξαρτήσεις errors για c++11 κάτι μπλα μπλα... Μετά πρέπει να κάνεις rebuild τις εξαρτήσεις και στη συνέχεια το ίδιο πακέτο... Παράδειγμα:

x86_64-pc-linux-gnu-g++ -D_REENTRANT -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -D_REENTRANT -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLOCALEDIR="/usr/share/locale" -DGLADE_FILE="/usr/share/pavucontrol/pavucontrol.glade" -O2 -pipe -march=native -mtune=native --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -std=c++11 -pipe -Wall -W -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o pavucontrol pavucontrol-minimalstreamwidget.o pavucontrol-channelwidget.o pavucontrol-streamwidget.o pavucontrol-devicewidget.o pavucontrol-cardwidget.o pavucontrol-sinkwidget.o pavucontrol-sourcewidget.o pavucontrol-sinkinputwidget.o pavucontrol-sourceoutputwidget.o pavucontrol-rolewidget.o pavucontrol-mainwindow.o pavucontrol-pavucontrol.o -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lcanberra-gtk3 -lX11 -lcanberra -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lpulse-mainloop-glib -lpulse -lglib-2.0
pavucontrol-channelwidget.o: In function `ChannelWidget::create()':
channelwidget.cc.text+0xb4c): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
channelwidget.cc.text+0xb8c): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-devicewidget.o: In function `DeviceWidget::renamePopup()':
devicewidget.cc.text+0x3854): undefined reference to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-cardwidget.o: In function `CardWidget::create()':
cardwidget.cc.text+0x12ff): undefined reference to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-sinkwidget.o: In function `SinkWidget::create(MainWindow*)':
sinkwidget.cc.text+0x2064): undefined reference to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-sourcewidget.o: In function `SourceWidget::create(MainWindow*)':
sourcewidget.cc.text+0x4b4): undefined reference to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-sinkinputwidget.o: In function `SinkInputWidget::create(MainWindow*)':
sinkinputwidget.cc.text+0x824): undefined reference to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
pavucontrol-sourceoutputwidget.o:sourceoutputwidget.cc.text+0x824): more undefined references to `Gtk::Builder::create_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)' follow
pavucontrol-mainwindow.o: In function `set_icon_name_fallback(Gtk::Image*, char const*, Gtk::IconSize) [clone .constprop.305]':
mainwindow.cc.text+0x63c): undefined reference to `Gtk::Image::set(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
mainwindow.cc.text+0x766): undefined reference to `Gtk::Image::set(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
mainwindow.cc.text+0x7eb): undefined reference to `Gtk::Image::set(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
mainwindow.cc.text+0x81b): undefined reference to `Gtk::Image::set(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
pavucontrol-mainwindow.o: In function `MainWindow::create(bool)':
mainwindow.cc.text+0x4122): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
mainwindow.cc.text+0x41d4): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
mainwindow.cc.text+0x429e): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
mainwindow.cc.text+0x436e): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
mainwindow.cc.text+0x443e): undefined reference to `Gtk::Builder::add_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*)'
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/libgtkmm-3.0.so: undefined reference to `Glib::ustring::ustring(std::string&&)'
/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/libgtkmm-3.0.so: undefined reference to `Glib::ustring::ustring(std::string const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:465: pavucontrol] Error 1
make[2]: Leaving directory '/var/tmp/portage/media-sound/pavucontrol-3.0/work/pavucontrol-3.0/src'
make[1]: *** [Makefile:413: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/media-sound/pavucontrol-3.0/work/pavucontrol-3.0'
make: *** [Makefile:353: all] Error 2
* ERROR: media-sound/pavucontrol-3.0::gentoo failed (compile phase):
* emake failed
*
* If you need support, post the output of `emerge --info '=media-sound/pavucontrol-3.0::gentoo'`,
* the complete build log and the output of `emerge -pqv '=media-sound/pavucontrol-3.0::gentoo'`.
* The complete build log is located at '/var/tmp/portage/media-sound/pavucontrol-3.0/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/media-sound/pavucontrol-3.0/temp/environment'.
* Working directory: '/var/tmp/portage/media-sound/pavucontrol-3.0/work/pavucontrol-3.0'
* S: '/var/tmp/portage/media-sound/pavucontrol-3.0/work/pavucontrol-3.0'

Με bold φαίνεται η προβληματική εξάρτηση (το dev-cpp/gtkmm στην προκειμένη περίπτωση), οπότε θέλει πρώτα rebuild εκείνο και μετά το pavucontrol.

- - - Updated - - -

Άσχετο: Πώς αλλάζω το theme για KDE 4 εφαρμογές (πχ. Amarok) μέσα από plasma; Κάτι έγινε τις τελευταίες μέρες με όλα αυτά τα rebuild των πακέτων και έχασα το look που είχα σε αυτές τις εφαρμογές...

[petran_18]

 revdep-rebuild --library 'libstdc\+\+\.so\.6' -- --exclude gcc

Ίσως σε βοηθήσει από την αρχή, τις πιο βασικές εξαρτήσεις του tree, να γίνουν built με το νέο ABI και standard.

Από εδώ

Title: GCC 5 Defaults to the New C++11 ABI
Author: Mike Frysinger <vapier@gentoo.org>
Content-Type: text/plain
Posted: 2015-10-22
Revision: 2
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-5

GCC 5 uses the new C++ ABI by default. When building new code, you might run
into link time errors that include lines similar to:
...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'

Or you might see linkage failures with "std::__cxx11::string" in the output.

These are signs that you need to rebuild packages using the new C++ ABI.
You can quickly do so by using revdep-rebuild (from gentoolkit).

For gentoolkit-0.3.1 or higher:
# revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

For previous versions of gentoolkit:
# revdep-rebuild --library 'libstdc\+\+\.so\.6' -- --exclude gcc

For more details, feel free to peruse:
https://developerblog.redhat.com/201...d-the-c11-abi/
https://blogs.gentoo.org/blueness/20...lem-in-gentoo/

[GoofyX]

Ναι, το ξέρω αυτό, αλλά το θέμα είναι ότι με αυτό τον τρόπο θα σου βγάλει καμιά 700-800αριά πακέτα... Προτιμώ να το κάνω με το χέρι όπου χρειάζεται.

[petran_18]

Ναι αλλά θα υπάρχει μια "συνοχή" στο σύστημα... Τέσπα εσύ ξέρεις τι θα κάνεις

[imitheos]

Ναι, το ξέρω αυτό, αλλά το θέμα είναι ότι με αυτό τον τρόπο θα σου βγάλει καμιά 700-800αριά πακέτα... Προτιμώ να το κάνω με το χέρι όπου χρειάζεται.

Ε δεν υποτίθεται όμως ότι αυτά τα 700-800 πακέτα _πρέπει_ να ξαναχτιστούν μια και εξαρτώνται από την libstdc και το abi είναι διαφορετικό ?