# kdehiddenvisibility

## Thargor

Hallo zusammen!

Was genau bewirkt

```
USE="kdehiddenvisibility"
```

```
Makes KDE symbols hidden by default, requires GCC 4.1 (experimental)
```

hilft mir irgendwie nicht wirklich weiter  :Sad: 

Danke im Vorraus,

Benedikt

----------

## monade

Wurde schonmal auf der gentoo-user-ML gefragt:

http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg35212.html

Hab es selbst noch nicht ausprobiert..

----------

## l3u

Die Frage is, ob's das bringt und ob's sicher ist ...

----------

## Hilefoks

 *Libby wrote:*   

> Die Frage is, ob's das bringt und ob's sicher ist ...

 

Ob es was bringt kann ich nicht wirklich sagen - vom Gefühl her würde ich ja sagen. Sicher, also im Bezug auf Stabilität und Kompatipilität, ist es. Inzwischen laufen alle Maschinen bei mir mit dieser Konfiguration und es gab bisher 0 Probleme. 

MfG,

Hilefoks

----------

## mrsteven

Das klingt ja ganz interessant. Ich werde das beim nächsten KDE-Update auch mal testen.

----------

## l3u

Naja, schreiben wir's halt mal rein in die allgemeinen USE-Flags ... man wird sehen, was passiert ;-) Hätt ich das früher gewußt, dann hätt ich das _vor_ meinem GCC-Update gemacht ;-)

----------

## Klaus Meier

Ich habs bei mir drin. Ob es daran liegt, oder daran, daß ich mein KDE jetzt mit -O3 gemacht habe, weiß ich nicht. Ich finde es momentan aber rasend schnell. Jedenfalls deutlich flotter als Gnome, was ich vorher benutzt habe. Und auch schneller, als ich KDE von früher in Erinnerung habe.

----------

## l3u

Ich hab jetzt grad auch mal den ganzen KDE-Kram neu gebaut ... vielleicht bild ich's mir ja nur ein, aber es scheint ein ganzes Eck schneller zu sein als vorher!

----------

## Martux

Hallo! Ja das ist wirklich interessant, ich baue auch gerade mein KDE-Zeug neu. Frage an die, die's schon haben: Startet nur KDE schneller oder betrifft das auch die einzelnen Programme? Immerhin sind es bei mir knapp 60 Pakete, die dieses useflag benutzen.

----------

## Klaus Meier

Hab da nicht so den Vergleich, weil bei mir KDE erst seit kurzem rund läuft. Starten von KDE ist relativ normal, aber die Programme starten alle sehr schnell und man kann ziemlich flott mit arbeiten.  War früher so, daß KDE manchmal sehr schnell war und unter Last brach es ziemlich ein. Im Vergleich dazu war Gnome konstanter. Nie richtig schnell und nie richtig langsam. Und KDE ist jetzt bei mir nur noch richtig schnell. Habe aber auch das Gefühl, daß der Kernel 2.6.18 da was gebracht hat, der kam ziemlich zeitgleich mit meiner KDE Installation.

Also ich denke, es bringt spürbar was.

----------

## Martux

 :Very Happy:   :Very Happy:  ++

Na da freue ich mich ja wenn das fertig ist. Bin leider erst bei 2 von 61...

Gruß, Marcus

----------

## Bloodsurfer

Hab auch schnell mal den Kram neu gemerged... Und was soll ich sagen, auch mir kommt es ne Ecke schneller vor. Der KDE Start wurde dadurch mehr beschleunigt als durch Prelink, sofern ich mir das jetzt nicht einbilde.

Nur ne kleine Zwischenfrage zur Sicherheit... Es hieß man muss QT neubauen vorher. Dafür gibt es aber dieses Useflag nicht. Heißt das man muss QT nur mit dem GCC 4.1 oder höher bauen und die Unterstützung ist dann automatisch drin?

Hab nämlich auf ein erneutes QT-Bauen verzichtet, weil ich eh alles nach meinem Update auf den neuen GCC neu emerged habe damals... 

Es scheint jedenfalls funktioniert zu haben.

----------

## l3u

Es hieß, daß man gcc-4.1 braucht, um dieses Feature nutzen zu können (sofern ich da jetzt nicht was verwechsle)

----------

## Klaus Meier

 *Bloodsurfer wrote:*   

> Hab auch schnell mal den Kram neu gemerged... Und was soll ich sagen, auch mir kommt es ne Ecke schneller vor. Der KDE Start wurde dadurch mehr beschleunigt als durch Prelink, sofern ich mir das jetzt nicht einbilde.
> 
> Nur ne kleine Zwischenfrage zur Sicherheit... Es hieß man muss QT neubauen vorher. Dafür gibt es aber dieses Useflag nicht. Heißt das man muss QT nur mit dem GCC 4.1 oder höher bauen und die Unterstützung ist dann automatisch drin?
> 
> Hab nämlich auf ein erneutes QT-Bauen verzichtet, weil ich eh alles nach meinem Update auf den neuen GCC neu emerged habe damals... 
> ...

 

Wüßte nicht, warum man qt neu bauen soll. Wichtig ist, daß man qt mit dem gleichen gcc übersetzt wie kde. Sonst meckert das. Und die Unterstützung ist wohl nicht im qt drin, sondern im kde. Denn nur da gibt es dieses Flag. Man kann aber auch manuell 

```
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
```

setzen, daß scheint ähnliches zu bewirken.

----------

## Martux

@bloodsurfer

bin ja auch grad am kompilieren und jedenfalls bringt er für jedes paket brav

```

--enable-gcc-hidden-visibility 

```

scheint also zu gehen.

habe mich auch schon gefragt ob es nicht sinn macht

```

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

```

zu setzen... davon könnten ja auch andere pakete profitieren. oder ist das dann wieder gericed  :Question: 

----------

## Klaus Meier

@Martux: Ich habs bei mir drin und bislang noch keine Probleme. Es gibt auch ne ganze Menge Pakete, die dieses Flag automatisch setzen, Firefox z.B.

----------

## dave87

 *Klaus Meier wrote:*   

> Und die Unterstützung ist wohl nicht im qt drin, sondern im kde. Denn nur da gibt es dieses Flag. Man kann aber auch manuell 
> 
> ```
> CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
> ```
> ...

 

Allerdings wird QT beim re-emergen mit dem qt-3.3.6-visibility.patch gepatcht. (Nur ob das jetzt am neuen GCC oder woran auch immer liegt weiss ich nicht)

----------

## franzf

Was auch noch mal was bringt, wäre ein gepatchtes ~QT-3.3.6 zu verwenden. z.B. das aus dem sabayon-overlay (layman -a sabayon)

```
USE="pertty risky" emerge =qt-3.3.6-r2
```

Wobei pertty stabil laufen sollte, risky manchmal Probleme bereiten kann (hier merk ich nix im Geringsten  :Smile: )

Soweit ich das verstanden hab ist das risky-flag für hiddenvisibility im QT verantwortlich.

Grüße

Franz

----------

## dave87

 *franzf wrote:*   

> Was auch noch mal was bringt, wäre ein gepatchtes ~QT-3.3.6 zu verwenden. z.B. das aus dem sabayon-overlay (layman -a sabayon)
> 
> ```
> USE="pertty risky" emerge =qt-3.3.6-r2
> ```
> ...

 

Werd ich gleich mal antesten. Nutze eh haupstsächlich Gnome, da störts nicht wenn KDE nicht so rund läuft und ich nen paar Sachen mehrmals bauen muss.

Wie bekommt man eigentlich so etwas raus, z.Bsp. welche Layman-Overlays alle qt enthalten.

----------

## franzf

 *dave87 wrote:*   

>  *franzf wrote:*   Was auch noch mal was bringt, wäre ein gepatchtes ~QT-3.3.6 zu verwenden. z.B. das aus dem sabayon-overlay (layman -a sabayon)
> 
> ```
> USE="pertty risky" emerge =qt-3.3.6-r2
> ```
> ...

 

Man muss den Erschaffer der Matrix kennen  :Smile: 

Am besten wendest du dich hier an diese Person.

Oder man liest viel hier mit.

Oder einfach mal die Overlays durchstöbern (die URLs zu denen findest du mit layman raus).

----------

## dave87

 *franzf wrote:*   

>  *dave87 wrote:*    *franzf wrote:*   Was auch noch mal was bringt, wäre ein gepatchtes ~QT-3.3.6 zu verwenden. z.B. das aus dem sabayon-overlay (layman -a sabayon)
> 
> ```
> USE="pertty risky" emerge =qt-3.3.6-r2
> ```
> ...

 

Mist, ich dachte es gibt so etwas wie packages.gentoo.org in denen alle overlays mit drin sind. Muss ich mich halt doch an den Operator wenden, dass er mir soetwas reinprogrammiert in die Matrix.   :Very Happy: 

Einzelne Overlays hab ich auch schon durchgeschaut, aber wenn man doch fast alle mal durchschauen will wird das irgendwie zeitaufwändig, besonders wenn man mal nix bestimmtes sucht, sondern bsp. irgendwas unbekanntes aus game-*/*.

----------

## monade

Also eix durchsucht doch standardmäßg die Layman-Overlays? Oder willst du Overlays durchsuchen, die du gar nicht "abonniert" hast?

----------

## dave87

 *monade wrote:*   

> Also eix durchsucht doch standardmäßg die Layman-Overlays? Oder willst du Overlays durchsuchen, die du gar nicht "abonniert" hast?

 

Jupp, ich würde gern alle, also auch die nichtabonierten, durchsuchen.

Wie ich die aboniere, damit sie nicht bei nem emerge miteinbezogen werden weiss ich schon (hab hier nen paar overlays local gemirrored), aber wie bekomm ich sie dann in eix rein?

//edit: theoretisch müsste es ja gehen, wenn ich vor dem update-eix die ganzen overlays zu portage hinzufüge damit sie einbezogen werden und dann wieder rausmache, nur hab ich dann das normale eix ja nicht mehr, also wär ne Möglichkeit doch 2 mal eix zu installieren, eins für alles und eins für das was portage auch nutzt (normaler portage tree und 1-3 overlays). Nur wie sag ich den eix'en dann welches welche pakete indexieren soll?

----------

## Keepoer

Ok, ich hab hier n Fehler!

kdehiddenvisibility in die make.conf eingetragen und dann ein emerge -avtuDN world. Er zeigt auch ganz artig viele KDE-Programme an. kdelibs sind mitlerweile durch. Kommt aber das nächste Paket (klinkstatus) dran, meckert er rum, dass ich das Use-Flag auch bei den kdelibs einkompilieren sollte. Beim ersten Mal hab ich dann einfach nochmal nur die kdelibs emerged. Dann noch X neugestartet. Wieder emerge -avtuDN world. Wieder der gleiche Fehler:

```
*** Creating configure

*** Creating config.h template

*** Creating Makefile templates

*** Postprocessing Makefile templates

*** Creating date/time stamp

*** Finished

    Don't forget to run ./configure

    If you haven't done so in a while, run ./configure --help

 * You asked to enable hidden visibility, but your kdelibs was

 * built without its support. Please rebuild kdelibs with the

 * kdehiddenvisibility useflag enabled.

!!! ERROR: kde-base/klinkstatus-3.5.2 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  ebuild.sh, line 1255:   Called kde-meta_src_compile

  kde-meta.eclass, line 379:   Called kde_src_compile

  kde.eclass, line 164:   Called kde_src_compile 'all'

  kde.eclass, line 331:   Called kde_src_compile 'myconf' 'configure' 'make'

  kde.eclass, line 272:   Called die

!!! kdelibs without hidden visibility

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

kdehiddenvisibility ist aber drin:

```
[ebuild   R   ] kde-base/kdelibs-3.5.2-r6  USE="alsa arts cups kdehiddenvisibility spell ssl -acl -debug -doc -jpeg2k -kdeenablefinal -kerberos -legacyssl -openexr -tiff -xinerama -zeroconf" 0 kB
```

Brauche Hilfe  :Wink: 

----------

## Thargor

Hast du schonmal qt (3 und evtl. 4) neu kompiliert? (nach dem setzen des USE-Flag und mit gcc4.1+)?

Stand ja mal irgendwo, dass man das machen sollte.

----------

## franzf

 *Thargor wrote:*   

> Hast du schonmal qt (3 und evtl. 4) neu kompiliert? (nach dem setzen des USE-Flag und mit gcc4.1+)?
> 
> Stand ja mal irgendwo, dass man das machen sollte.

 

kdehiddenvisibility hat nun mal nur was mit kde zu tun. Deshalb bringt imo ein Neukomilieren von QT nix...

Find ich komisch, das Problem...

----------

## Martux

Sorry kann ich nix zu sagen. Wollte nur erwähnen, daß ich finde das sehr wohl auch Programme schneller starten, spürbar. Wenn ich mir mal das Kontrollzentrum anschaue, find ich's richtig geil  :Smile: 

----------

## dave87

 *Thargor wrote:*   

> Hast du schonmal qt (3 und evtl. 4) neu kompiliert? (nach dem setzen des USE-Flag und mit gcc4.1+)?
> 
> Stand ja mal irgendwo, dass man das machen sollte.

 

Stand in der Mailinglist (Link weiter oben), ob allerdings die USEFlag was an qt ändert, wenn qt doch diese USEFlag garnicht zur Auswahl hat? Schaden dürfte es jedoch nicht.

Vielleicht noch Reste der alten kdelibs drauf? oder mehrere Versionen? was passiert wenn du's runterwerfst und neuinstallierst? (nur die kdelibs nicht kde  :Wink:  )

Hast du in der package.use vielleicht für manche Pakete kdehiddenvisibility deaktiviert?

//edit: Ich hatte zwar nun längere Zeit Gnome (atm 2.16.0) und kein KDE mehr, allerdings kommt mir KDE nun wirklich schneller vor als ich es in Erinnerung hab.

----------

## Klaus Meier

 *Martux wrote:*   

> Sorry kann ich nix zu sagen. Wollte nur erwähnen, daß ich finde das sehr wohl auch Programme schneller starten, spürbar. Wenn ich mir mal das Kontrollzentrum anschaue, find ich's richtig geil 

 Sach ich ja, geht ab wie ne Rakete!

----------

## xraver

 *Klaus Meier wrote:*   

>  *Martux wrote:*   Sorry kann ich nix zu sagen. Wollte nur erwähnen, daß ich finde das sehr wohl auch Programme schneller starten, spürbar. Wenn ich mir mal das Kontrollzentrum anschaue, find ich's richtig geil  Sach ich ja, geht ab wie ne Rakete!

 

Dann werd ich mir diesen Raketentreibstoff auch mal ansehen.

----------

## Keepoer

Also,

nachdem ich sowohl qt3 als auch qt4 neu gemerged hab (obwohl beide nicht das entsprechende USE-Flag haben), danach die kdelibs neu gebaut habe, läufts jetzt wunderbar durch.  :Smile: 

Mal sehen, was das jetzt bringt...

----------

## slick

Von dem der es problemlos umgestellt hat und mit der Leistung zufrieden ist würde ich mir gern im Interesse aller und natürlich im eigenen Interesse ein kurzes Step-by-Step HowTo wünschen was mal alles hier zusammenfasst. Welche Pakete werden benötigt bzw. mit welchen useflags wie remergt werden. Irgendwie ist es mühselig das sich an verschiedenen Stellen zusammenlesen zu müssen.

----------

## nikaya

Nachdem einem durch diesen Thread dieses Flag ja richtig schmackhaft gemacht wurde,werde ich es auch mal versuchen.

Ich blicke trotzdem nicht genau was dieses Flag jetzt bewirkt.

Der obige Link hat dort diesen Link enthalten.Daraus lese ich aber nur dass die Ladezeiten von Shared Libraries erheblich verkürzt werden.Ja warum wird es dann nicht standardmäßig aktiviert?Wo sind die Nachteile?Kann das mal jemand einem interessierten Laien erklären?

Und warum heißt es "hiddenvisibility",also "versteckte Sichtbarkeit"?

Fragen über Fragen.

----------

## firefly

vorher wurde jedes symbol einer library exportiert, durch das setzten dieses flags, werden dann nur noch die symbole erportiert, welche auch von anderen programmen benötigt werde und der rest ist für andere programme libs nicht mehr sichtbar. D.h. der dynamic lib loader muss dadurch nicht mehr eine risiege export tabelle durchgehen um festzustellen ob alle abhängikeiten erfüllt werden. Dadurch beschleunigt sich das laden der Libraries

Und so in etwa steht es auch auf der seite  :Wink: 

----------

## franzf

@slick:

Unbedingt notwendig ist der neueste GCC. Wird aber mittlerweile eh schon jeder (mehr oder weniger) am Laufen haben.

Dann setzt du am besten global das kdehiddenvisibility-Flag.

Wenn du pertty + risky-patch für den ~qt-3.3.6 (->layman->sabayon) haben willst ebenfalls setzen (Ich hoffe du weißt wie man das macht...)

Und dann hab ich nur einen emerge -uDNavt world gestartet und alles lief rund.

Beim Keepoer hat sich ja scheinbar portage gemeldet nach der Umstellung bitte noch qt3/4 neu mergen, hier war das nicht nötig.

Dann einen Kaffee holen denn das wird sicher lange dauern (so ähnlich stehts doch immer in den Dokus  :Smile: ).

Ich hatte mit keinem Paket Probleme mit den Patches, es hat alles kompiliert und läuft alles. Mittlerweile auch mit risky (hatte damit anfangs Probleme, konnte nichts damit kompilieren...).

Ich denke das sollte eine der einfacheren Umstellungen sein  :Smile: 

-> Hier der Gentoo-Foren-Thread zu qt-copy.

----------

## nikaya

 *firefly wrote:*   

> vorher wurde jedes symbol einer library exportiert, durch das setzten dieses flags, werden dann nur noch die symbole erportiert, welche auch von anderen programmen benötigt werde und der rest ist für andere programme libs nicht mehr sichtbar. D.h. der dynamic lib loader muss dadurch nicht mehr eine risiege export tabelle durchgehen um festzustellen ob alle abhängikeiten erfüllt werden. Dadurch beschleunigt sich das laden der Libraries
> 
> Und so in etwa steht es auch auf der seite 

 

Danke,hast mir etwas Licht ins Dunkel gebracht.

----------

## firefly

Ach ja, es wurde deshalb vorher nicht verwendet, weil der gcc vor 4.0 keinen support dafür hatte  :Wink: 

----------

## Klaus Meier

 *slick wrote:*   

> Von dem der es problemlos umgestellt hat und mit der Leistung zufrieden ist würde ich mir gern im Interesse aller und natürlich im eigenen Interesse ein kurzes Step-by-Step HowTo wünschen was mal alles hier zusammenfasst. Welche Pakete werden benötigt bzw. mit welchen useflags wie remergt werden. Irgendwie ist es mühselig das sich an verschiedenen Stellen zusammenlesen zu müssen.

  Ist doch gar nicht so schwierig. Du brauchst ein aktuelles System. Also den gcc 4.1.1.  Dann das Flag kdehiddenvisibily setzen. Dann eventuell dein benötigtes qt neu übersetzen, scheint nötig zu sein. Und dann ein emerge -uDN world.Last edited by Klaus Meier on Fri Sep 29, 2006 11:08 am; edited 1 time in total

----------

## l3u

Also ich hab's nur in die global USE-Flags in /etc/make.conf reingeschrieben und ein emerge -uavD --newuse world gemacht. Das war's :-)

----------

## slick

 *Libby wrote:*   

> in /etc/make.conf reingeschrieben und ein emerge -uavD --newuse world 

 

remerge läuft...

----------

## Keepoer

Alter Schwede!   :Shocked: 

Ist ja geil schnell...

Danke für den Tip!   :Very Happy: 

----------

## slick

Also rein subjektiv läuft KDE-Zeugs jetzt wirklich schneller. Und wirklich easy zu machen ... useflag in die conf und pakete remergen. Super Tipp!

----------

## franzf

@slick, keepoer:

Habt ihr nur die kde-Sachen mit kdehiddenvisibility gemacht?

Oder auch qt mit pertty (->sind die patches des kde-teams an der qt-lib) oder sogar risky?

Von kdehiddenvisibility allein hab ich auf meinem (doch recht schnellen) Rechner nicht SOOOOVIEL gemerkt. Spürbar was gebracht hat das pertty, richtig geboostet hats mit risky  :Wink: 

(Man kann sich vorm Testen ja erst ein Package schnüren -> quickpkg ~qt-3.3.6)

Grüße

Franz

----------

## Klaus Meier

 *franzf wrote:*   

> @slick, keepoer:
> 
> Habt ihr nur die kde-Sachen mit kdehiddenvisibility gemacht?
> 
> Oder auch qt mit pertty (->sind die patches des kde-teams an der qt-lib) oder sogar risky?
> ...

 Also bei mir hat kdehiddenvisibility schon richtig was gebracht. Hab noch nie was mit Layman gemacht, gib doch mal ne schnelle Anleitung rüber, wie man damit an das gepatchte Qt kommt. Also wenn das noch schneller wird, dann verkaufe ich meinen Rechner und hole mir einen Athlon 1000. Ist ja gar nicht mehr auszuhalten vor Tempo.

----------

## slick

 *franzf wrote:*   

> @slick, keepoer:
> 
> Habt ihr nur die kde-Sachen mit kdehiddenvisibility gemacht?

 

Nur kdehiddenvisibility, und wie gesagt "subjektiv" ... kann auch sein ich habe schlecht geschlafen und alles fühlt sich jetzt besser an...  :Wink:  Wie safe sind pertty und risky?

----------

## Martux

 :Very Happy:   :Very Happy:   :Very Happy: 

Also bei mir hat kdehiddenvisibility *extrem* was gebracht

```

emerge layman 

layman -a sabayon   

USE="pertty risky" emerge =qt-3.3.6-r2

```

nicht mehr spürbar was. Oder hätte ich nicht beide flags nehmen sollen?

Gruß, Marcus

PS: die cxx-flags fvisibility-inlines-hidden zu setzen hat bei mir das System total zerstört, kann ich also gar nicht empfehlen  :Wink: 

----------

## franzf

 *Klaus Meier wrote:*   

>  *franzf wrote:*   @slick, keepoer:
> 
> Habt ihr nur die kde-Sachen mit kdehiddenvisibility gemacht?
> 
> Oder auch qt mit pertty (->sind die patches des kde-teams an der qt-lib) oder sogar risky?
> ...

 

```
emerge layman

layman -L  // zeigt alle vorhandenen Overlalys an

// evtl. vorher noch die /etc/layman/layman.cfg anpassen -> mir gefiel das overlay nach /usr/portage/local nicht ;)

// ich habs auf /usr/local/layman gesetzt.

layman -a sabayon // hier sind viele interessante Sachen -> beryl, qt, etc

// Eintrag in /etc/make.conf: source /Pfad/zum/Layman-overlay/make.conf

// damit du nicht für jedes Overlay, das du mit layman hinzufügst, deine make.conf editieren musst ;)

// evtl.Konsole schließen/ausloggen, damit das Overlay in deinem "emerge-Path" steht

emerge WAS_IMMER IM_OVERLAY_IST, z.B.:

USE="pertty risky" emerge ~qt-3.3.6
```

Steht alles auch in man layman oder auf deren Homepage.

Grüße

Franz

----------

## franzf

 *slick wrote:*   

>  *franzf wrote:*   @slick, keepoer:
> 
> Habt ihr nur die kde-Sachen mit kdehiddenvisibility gemacht? 
> 
> Nur kdehiddenvisibility, und wie gesagt "subjektiv" ... kann auch sein ich habe schlecht geschlafen und alles fühlt sich jetzt besser an...  Wie safe sind pertty und risky?

 

pertty sollte sicher laufen, die Bezeichnung für das Flag risky sagt eigentlich schon alles  :Very Happy:  (Hier passt aber alles, keine Stabilitäts-Probleme)

Wenn ihr die qt-libs gepatcht installiert werdet ihr auch in den Genuss von schnellen QT-Only-Apps kommen.

Z.B. die ganzen Konfig-Dialoge der Karamba-Themes (->PyQT) schießen nur so hoch, genauso schnell wie normale Binary-apps. War vorher immer relativ "gemütlich", der Start  :Smile: 

----------

## monade

Also diese USE-Flags (kdehiddenvisibility,pertty,risky) bringen dann alle nur beim Starten der Apps Performance-Vorteile, und nicht für den laufenden Betrieb?

Ich stell jedenfalls fest, dass kde-base/konsole, seitdem ich sie mit kdehiddenvisibility emerged hab, absolut träge geworden ist. Also nicht beim Starten, sondern im Betrieb, zB beim Wechseln der Tabs.. Aber das auch nur mein subjektiver Eindruck, vllt liegt es auch einfach an der Version (3.5.4-r1, vorher 3.5.4).

edit: hier stand noch quatsch.

----------

## nikaya

So,habe jetzt mein testing erstmal mit kdehiddenvisibility gemerged.Das stable folgt noch.

Ich meine auch dass es subjektiv schneller geworden ist,kann ich jetzt aber auch drauf konditioniert sein nachdem alle anderen schon so geschwärmt haben.QT brauchte ich nicht neu kompilieren,nur bei kdelibs moserte er erst herum.Nachdem ich diese kompiliert hatte lief es sauber durch.

Tolle Sache.

----------

## Polynomial-C

Hi,

also bei mir ließ sich kaffeine-0.8.2-r1 nicht mit kdehiddenvisibility kompilieren:

```
/bin/sh ../../../../libtool --silent --tag=CXX --mode=compile i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../../.. -I../../../../kaffeine/src/ -I../../../../kaffeine/src/player-parts/ -I/usr/kde/3.5/include -I/usr/qt/3/include -I.  -I/usr/kde/3.5/include -I/usr/include  -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wno-long-long -Wundef -fasynchronous-unwind-tables -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -march=athlon-xp -mtune=athlon-xp -O3 -pipe -frename-registers -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -fvisibility=hidden -fvisibility-inlines-hidden  -c -o kxinewidget.lo kxinewidget.cpp

kxinewidget.cpp: In member function 'QTime KXineWidget::getLengthInfo()':

kxinewidget.cpp:3793: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://bugs.gentoo.org/> for instructions.

Preprocessed source stored into /home/portage/tmp/portage/kaffeine-0.8.2-r1/temp/ccQeaIYY.out file, please attach this to your bugreport.

make[5]: *** [kxinewidget.lo] Error 1

make[5]: Leaving directory `/home/portage/tmp/portage/kaffeine-0.8.2-r1/work/kaffeine/kaffeine/src/player-parts/xine-part'

make[4]: *** [all-recursive] Error 1

make[4]: Leaving directory `/home/portage/tmp/portage/kaffeine-0.8.2-r1/work/kaffeine/kaffeine/src/player-parts'

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory `/home/portage/tmp/portage/kaffeine-0.8.2-r1/work/kaffeine/kaffeine/src'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/portage/tmp/portage/kaffeine-0.8.2-r1/work/kaffeine/kaffeine'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/portage/tmp/portage/kaffeine-0.8.2-r1/work/kaffeine'

make: *** [all] Error 2

!!! ERROR: media-video/kaffeine-0.8.2-r1 failed.

Call stack:

  ebuild.sh, line 1546:   Called dyn_compile

  ebuild.sh, line 937:   Called src_compile

  kaffeine-0.8.2-r1.ebuild, line 63:   Called kde_src_compile

  kde.eclass, line 164:   Called kde_src_compile 'all'

  kde.eclass, line 331:   Called kde_src_compile 'myconf' 'configure' 'make'

  kde.eclass, line 327:   Called die

!!! died running emake, kde_src_compile:make

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

Ist hier vielleicht noch jemand über den Fehler gestolpert? Ohne kdehiddenvisibility kompiliert kaffeine sauber durch und kaffeine ist auch das einzige Paket, daß mit dem Flag nicht kompiliert.

Grüße

Poly-C

----------

## Keepoer

Scheint sich eher um einen Bug zu handeln:

```
kxinewidget.cpp: In member function 'QTime KXineWidget::getLengthInfo()':

kxinewidget.cpp:3793: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://bugs.gentoo.org/> for instructions.

Preprocessed source stored into /home/portage/tmp/portage/kaffeine-0.8.2-r1/temp/ccQeaIYY.out file, please attach this to your bugreport.
```

Ich hatte bis die kdelibs keine Probleme...

----------

## Klaus Meier

Ich bekomme bei mir immer internal compiler error, wenn ich versuche, Kaffeine mit -O3 zu übersetzen. Mit -O2 und kdehiddennvisibility geht es bei mir durch. Würde da mal sagen, entweder Kaffeine oder gcc, einer von beiden hat noch Macken.

----------

## Klaus Meier

Ich bekomme bei mir immer internal compiler error, wenn ich versuche, Kaffeine mit -O3 zu übersetzen. Mit -O2 und kdehiddennvisibility geht es bei mir durch. Würde da mal sagen, entweder Kaffeine oder gcc, einer von beiden hat noch Macken. Hast du denn gcc 4.1.1-r1? Der ohne r1 macht mit KDE nur Streß.

----------

## Polynomial-C

Hi,

 *Klaus Meier wrote:*   

> Hast du denn gcc 4.1.1-r1? Der ohne r1 macht mit KDE nur Streß.

 

obwohl ich hier ein ~x86 System laufen habe, lasse ich von einigen Paketen nur die als stable markierten Versionen installieren. Dazu zählt ebenfalls gcc, womit ich im Moment noch gcc-4.1.1 installiert habe und auch benutze.

Grüße

Poly-C

----------

## Klaus Meier

 *Polynomial-C wrote:*   

> Hi,
> 
>  *Klaus Meier wrote:*   Hast du denn gcc 4.1.1-r1? Der ohne r1 macht mit KDE nur Streß. 
> 
> obwohl ich hier ein ~x86 System laufen habe, lasse ich von einigen Paketen nur die als stable markierten Versionen installieren. Dazu zählt ebenfalls gcc, womit ich im Moment noch gcc-4.1.1 installiert habe und auch benutze.
> ...

 Schmeiß ihn weg. Der gcc-4.1.1 bekommt kein KDE hin. Hat bei mir nur Streß gemacht. Gingen zwar alle Pakete durch, aber irgendwas hat immer nicht funktioniert. Mit den 4.1.1-r1 läuft alles super, sogar mit -O3. Bis auf Kaffeine, welches internal compiler na und so weiter meldet. Aber mit -O2 geht es dann durch.

----------

## Hilefoks

bei mir geht der gcc-4.1.1 ohne Probleme (allerdings nutze ich Kaffeine nicht und optimiere mit 02).

----------

## Klaus Meier

 *Hilefoks wrote:*   

> bei mir geht der gcc-4.1.1 ohne Probleme (allerdings nutze ich Kaffeine nicht und optimiere mit 02).

 Entschuldige jetzt bitte meine etwas patzigen Worte, aber dazu kann ich nur sagen: Die Tatsache, daß es bei dir keine Probleme gibt, ist kein Beweis für die Fehlerfreiheit des gcc-4.1.1. Jeder reproduzierbare Fehler ist aber ein Beweis dafür, daß der gcc-4.1.1 Fehler hat. Normale Beweisführung in der Mathematik.

Genauso wie der Satz:"Alle Raben sind schwarz" nicht zu beweisen ist. Aber man kann ihn durch einen weißen Raben wiederlegen.

----------

## nikaya

 *Klaus Meier wrote:*   

>  *Hilefoks wrote:*   bei mir geht der gcc-4.1.1 ohne Probleme (allerdings nutze ich Kaffeine nicht und optimiere mit 02). Entschuldige jetzt bitte meine etwas patzigen Worte, aber dazu kann ich nur sagen: Die Tatsache, daß es bei dir keine Probleme gibt, ist kein Beweis für die Fehlerfreiheit des gcc-4.1.1. Jeder reproduzierbare Fehler ist aber ein Beweis dafür, daß der gcc-4.1.1 Fehler hat. Normale Beweisführung in der Mathematik.
> 
> .

 

Hat Hilefoks ja auch nie behauptet.Er hat nur gesagt dass es bei ihm ohne Probleme klappt.Seine Aussage ist nur ein Beweis dass gcc nicht nur Fehler produziert,sondern dass es auch Rechner geben kann wo es einfach funktioniert.Eine Einschränkung hat er ja in Klammern gesetzt.

----------

## moe

 *Klaus Meier wrote:*   

>  *Hilefoks wrote:*   bei mir geht der gcc-4.1.1 ohne Probleme (allerdings nutze ich Kaffeine nicht und optimiere mit 02). Entschuldige jetzt bitte meine etwas patzigen Worte, aber dazu kann ich nur sagen: Die Tatsache, daß es bei dir keine Probleme gibt, ist kein Beweis für die Fehlerfreiheit des gcc-4.1.1. Jeder reproduzierbare Fehler ist aber ein Beweis dafür, daß der gcc-4.1.1 Fehler hat. Normale Beweisführung in der Mathematik.
> 
> 

 

Eine normale Beweisführung wäre hier, dass du das changelog des gcc-4.1.1->4.1.1-r1 liest, und dort möglicherweise Sachen findest, die deine Vermutung bestätigen. Ein Sprung von nichts zu r1 ist ja nur gentoo-intern, also brauchst du nichtmal auf die Seite vom gcc und deren Changelogs gehen.

Reproduzierbar bedeutet übrigens auch, dass derselbe Fehler auf einem anderen identischen Rechner auftrittst, oder dass du denselben Fehler wieder erhältst wenn du nochmal den gcc-4.1.1 installierst. Vielleicht war ja beim ersten Installieren irgendeine Abhängigkeit noch in einer anderen Version vorhanden und diese hat den Fehler verursacht?

Bei mir lief die Installation auf einem relativ frischem Gentoo-2006.1 System mit O3 und kdehiddenvisibility problemlos durch, und kde ist auch problemlos nutzbar. Kaffeine hab ich allerdings auch nicht installiert.

Gruss Maurice

----------

## Yonathan

muss qt-4* eigentlich nun auch noch reemerged werden, nachdem man qt-3* mit den  neuen use-flags emerged hat?

----------

## moe

Welche neuen USE-Flags? qt3 muss nur reemerged werden wenn es davor nicht mit gcc-4 kompiliert wurde, neue USE-Flags gibts nur mit qt-ebuilds aus irgendwelchen Overlays.

Aber da kde qt4 momentan überhaupt gar nicht nutzt oder braucht, sage ich mal spontan nein.

----------

## Yonathan

hmm... habe auf jeden fall beides drauf...

qt-3.3.6-r2 <-- kam mit dem sabayon-overlay

qt-4.1.4

waren beide nicht mit einem neuen gcc emerged, meine ich, es sei denn sie werden beim emerge -e system mitgemerged.

[edit] ist es normal, dass jetzt so viele pakete zu neu-emergen da sind:

```
[ebuild   R   ] media-libs/mesa-6.5.1-r1  USE="-motif*"

[ebuild   R   ] app-editors/nano-1.3.12-r1  USE="-spell*"

[ebuild   R   ] dev-db/unixODBC-2.2.11-r1  USE="-qt3*"

[ebuild   R   ] media-sound/sox-12.17.9  USE="-mad*"

[ebuild   R   ] media-libs/libao-0.8.5  USE="-esd*"

[ebuild   R   ] kde-base/kdelibs-3.5.4-r2  USE="-spell*"

[ebuild   R   ] net-irc/kvirc-3.2.0  USE="-esd*"

[ebuild   R   ] dev-lang/php-5.1.6-r4  USE="-spell*"

[ebuild   R   ] app-doc/doxygen-1.4.7  USE="-qt3*"

[ebuild   R   ] sys-apps/dbus-0.62-r1  USE="-qt3*"

[ebuild   R   ] app-text/poppler-bindings-0.5.4  USE="-qt3*"

[ebuild   R   ] app-emulation/wine-0.9.22  USE="-esd*"

[ebuild   R   ] media-libs/libsdl-1.2.11  USE="-esd* -xv*"

[ebuild   R   ] media-sound/xmms-1.2.10-r15  USE="-esd* -mad* -mikmod* -vorbis*"

[ebuild   R   ] media-video/ffmpeg-0.4.9_p20060530  USE="-vorbis*"

[ebuild   R   ] media-libs/xine-lib-1.1.2-r2  USE="-esd* -mad* -vorbis* -xv*"

[ebuild   R   ] media-video/kaffeine-0.7.1-r2  USE="-gstreamer*"

[ebuild   R   ] media-libs/sdl-sound-1.0.1-r1  USE="-mikmod* -vorbis*"

[ebuild   R   ] media-libs/libdv-0.102  USE="-xv*"

[ebuild   R   ] media-libs/openal-0.0.8  USE="-esd* -vorbis*"

[ebuild   R   ] media-video/mplayer-1.0_pre8-r1  USE="-esd* -mad* -vorbis* -xv*"

[ebuild   R   ] media-sound/normalize-0.7.6-r2  USE="-mad*"

[ebuild   R   ] kde-base/kdemultimedia-kioslaves-3.5.4  USE="-vorbis*"

[ebuild   R   ] app-cdr/k3b-0.12.17  USE="-vorbis*"

```

 ?

werden die use-flags von den paketen dann nicht mehr gebraucht bzw die unterstützung für das, was die use-flags da einbringen?

----------

## Polynomial-C

Hi,

 *Klaus Meier wrote:*   

> Schmeiß ihn weg. Der gcc-4.1.1 bekommt kein KDE hin. Hat bei mir nur Streß gemacht. Gingen zwar alle Pakete durch, aber irgendwas hat immer nicht funktioniert. Mit den 4.1.1-r1 läuft alles super, sogar mit -O3. Bis auf Kaffeine, welches internal compiler na und so weiter meldet. Aber mit -O2 geht es dann durch.

 

das kann ich hier nicht nachvollziehen. Meine CXXFLAGS sind -march=athlon-xp -mtune=athlon-xp -O3 -pipe -frename-registers -fvisibility-inlines-hidden und damit habe ich mir mein komplettes KDE zusammenkompiliert. Wie bereits erwähnt, macht kaffeine auch nur dann Ärger, wenn ich das kdehiddenvisibility useflag aktiviert habe. Ansonsten macht mir gcc-4.1.1 keinerlei Schwierigkeiten. 

Daß ich bei der Fehlermeldung aufgefordert werde, das Ganze als Bug zu melden, ist mir schon aufgefallen. Nur möchte ich, bevor ich das melde, erst mal wissen, ob noch andere von diesem speziellen Bug betroffen sind, oder ob der Fehler bei mir ein Einzelfall ist, der vielleicht durch andere Sachen verursacht wird (z.B. durch LDFLAGS="-Wl,--as-needed" das ich bei mir standardmäßig aktiviert habe).

Grüße

Poly-C

P.S.: Ja ich weiß, meine C(XX)FLAGS sind redundant. Das hat seine Gründe  :Smile: 

----------

## Thargor

Ich überlege grade, auch das qt aus dem sabayon overlay zu installieren.

Muss ich nach dem setzten der neuen USE-Flags auch die kdelibs bzw. ganz kde neubauen?

----------

## franzf

Im allerschlimmsten Fall (steht aber auch nach dem Merge von QT) die QT-Plugins, was in den meisten Fällen nur Styles sind  :Wink: 

Also kdelibs (->Plastik, usw sind da drin), und alles was du sonst noch gern mal siehst  :Wink: 

Du kannst also ganz easy schaun obs notwendig wird, wenn du dich ausloggst -> einloggst -> und dein Style nimmer angewendet wurde.

Bei nem Update von 3.3.6-r1 -> 3.3.6-r2 ging alles glatt. Von ~3.3.4 -> 3.3.6 musste ich diese Sachen neu bauen.

Gerüße

Franz

----------

## Necoro

Ich wollte nur mal einwerfen, dass es durchaus einige Programme gibt, die das von sich aus nutzen ... ich kompiliere gerade gettext ... und beim vorbeirauschen derr gcc-meldungen sehe ich, dass da überall "-fvisibility=hidden" drin steht  :Smile:  ...

(und nein - es steht nicht in meinen CFLAGS) ...

P.S. oh ... wie es ausschaut, ist das feature neu ... weil warum will er sonst alles neubauen, was gegen diese lib linkt?  :Wink: 

----------

## schachti

 *monade wrote:*   

> Also diese USE-Flags (kdehiddenvisibility,pertty,risky) bringen dann alle nur beim Starten der Apps Performance-Vorteile, und nicht für den laufenden Betrieb?
> 
> 

 

Das bringt vor allem was für die Startzeiten, sollte es aber auch ermöglichen, daß der Compiler besser optimiert (siehe http://gcc.gnu.org/wiki/Visibility).

----------

## hurra

So, ich werd das Useflag wieder rausnehmen. 

Die Anwendungen starten zwar wirklich schneller, jedoch hab ich schon ein paar Abstürze bekommen, die früher eigentlich nicht vorkamen. 

Hat da eventuell jemand auch noch so eine Erfahrung gemacht?

----------

## schachti

Ich kann nur sagen, daß bei mir alles problemlos und schneller als vorher läuft (seit einigen Wochen).

----------

## Bloodsurfer

Es läuft alles schneller als vorher. Probleme stelle ich keine fest bisher.

----------

## Keepoer

Also ich habe hier teilweise Probleme, aber es hält sich in Grenzen. Bisher konnte ich Amarok und Krusader nicht mehr starten. Fehler:

```
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6: version `CXXABI_1.3.1' not found (required by /usr/kde/3.5/lib/libkhtml.so.4)

```

Ok, ich war auch zu faul, nach dem Update auf gcc-4.1 mir eine neue Welt zu bauen, aber lassen wir das.  :Wink: 

Was mir nur auffällt ist der Umstand, dass beide Programme gar keine Unterstützung für das USE-Flag haben...

----------

## mrsteven

 *Keepoer wrote:*   

> Ok, ich war auch zu faul, nach dem Update auf gcc-4.1 mir eine neue Welt zu bauen, aber lassen wir das. 
> 
> Was mir nur auffällt ist der Umstand, dass beide Programme gar keine Unterstützung für das USE-Flag haben...

 

Na ja, die Fehlermeldung ist wirklich *ganz* typisch für ein (absichtlich) vergessenes emerge -e world, insofern wundert mich da gar nix...  :Rolling Eyes: 

----------

## slick

Bei einem Rechner lief die Umstellung auf kdehiddenvisibility super, einfach in die make.conf und emerge -uDN world. Beim anderen Rechner habe ich mindestens schon 3x die kdelibs mit kdehiddenvisibility gebaut, aber die anderen kde-Pakete sind immer der Meinung die kdelibs wären ohne kdehiddenvisibility gebaut und brechen ab. Jemand eine Idee dazu?

```
 * You asked to enable hidden visibility, but your kdelibs was

 * built without its support. Please rebuild kdelibs with the

 * kdehiddenvisibility useflag enabled.
```

----------

## May-C

Läuft alles einiges schneller. Mit risky ist es gleich nocht vieeeeeeeeeeeeel schneller. Dumm nur, dass mit risky bei mir net-im/psi nicht kompilierte. net-im/kopete lässt sich zwar emergen nur starten funktioniert nicht im Gegensatz zu kde-base/kopete...

Auf jeden fall habe ich risky wieder rausgenommen, obwohl die Geschwindigkeit irre ist   :Laughing: 

----------

## nikaya

 *slick wrote:*   

> Bei einem Rechner lief die Umstellung auf kdehiddenvisibility super, einfach in die make.conf und emerge -uDN world. Beim anderen Rechner habe ich mindestens schon 3x die kdelibs mit kdehiddenvisibility gebaut, aber die anderen kde-Pakete sind immer der Meinung die kdelibs wären ohne kdehiddenvisibility gebaut und brechen ab. Jemand eine Idee dazu?
> 
> ```
>  * You asked to enable hidden visibility, but your kdelibs was
> 
> ...

 

Keepoer hatte in diesem Thread das gleiche Problem.Hast Du mal versucht QT neu zu mergen?Das hat bei ihm geholfen.

----------

## Klaus Meier

 *slick wrote:*   

> Bei einem Rechner lief die Umstellung auf kdehiddenvisibility super, einfach in die make.conf und emerge -uDN world. Beim anderen Rechner habe ich mindestens schon 3x die kdelibs mit kdehiddenvisibility gebaut, aber die anderen kde-Pakete sind immer der Meinung die kdelibs wären ohne kdehiddenvisibility gebaut und brechen ab. Jemand eine Idee dazu?
> 
> ```
>  * You asked to enable hidden visibility, but your kdelibs was
> 
> ...

 Probier mal, das qt neu zu emergen. Hatte vorher schon mal jemand gepostet, daß er das mußte. Aber bitte nicht einfach emerge qt, sondern genau die Version aus dem KDE.

----------

## Carlo

slick: confcache?

----------

## slick

 *Klaus Meier wrote:*   

> Probier mal, das qt neu zu emergen. 

 

Das wars ... Thanks

----------

## McEnroe

 *Carlo wrote:*   

> slick: confcache?

 

funktioniert das überhaupt? ich glaub es is hard masked...

----------

## slick

Also gerade bei den hunderten KDE-Paketen macht das schon Sinn (und ich meine afaik da ist es auch safe). Generell würde ich es aber nicht einsetzen. Da müßte es irgendwo auch einen deutschen Thread oder ein paar Postings zu dem Thema geben. 

Edith sagt da ist der Thread: https://forums.gentoo.org/viewtopic-p-3415239.html#3415239

----------

## Klaus Meier

Also ich hätte mir bei KDE auch confcache gewünscht. Aber seit dem es hardmasked ist, fasse ich eś erst mal nicht mehr an. Testing ok, aber bei so elementaren Dingen habe ich Hemmungen mit Hardmasked.

----------

## Thargor

Eigentlich läuft's ganz gut.

Man muss nur den cache löschen, wenn man die toolchain updatet, bzw. wenn man so wie hier etwas ändert, was sich auf den Inhalt des Cache auswirkt (in diesem Fall -fvisibility-hidden)

Und man muss halt, wenn ein Paket nicht kompiliert es zuerst mit FEATURES="-confcache" probieren.

----------

## Klaus Meier

 *Thargor wrote:*   

> Eigentlich läuft's ganz gut.
> 
> Man muss nur den cache löschen, wenn man die toolchain updatet, bzw. wenn man so wie hier etwas ändert, was sich auf den Inhalt des Cache auswirkt (in diesem Fall -fvisibility-hidden)
> 
> Und man muss halt, wenn ein Paket nicht kompiliert es zuerst mit FEATURES="-confcache" probieren.

 Nein Danke, ist mir zu stressig. Sowas sollte confcache ja eigentlich selber merken. Wäre schön gewesen, aber es gibt so schon genug Probleme, wo man nicht sofort weiß, wo sie herkommen. Da brauche ich nicht noch eins.

----------

## schachti

 *slick wrote:*   

> Also gerade bei den hunderten KDE-Paketen macht das schon Sinn (und ich meine afaik da ist es auch safe).

 

ok, ich habe confcache für das Update von 3.5.4 auf 3.5.5 gerade mal wieder aktiviert - ich bin gespannt, ob das Update damit durchläuft.

----------

## Klaus Meier

 *schachti wrote:*   

>  *slick wrote:*   Also gerade bei den hunderten KDE-Paketen macht das schon Sinn (und ich meine afaik da ist es auch safe). 
> 
> ok, ich habe confcache für das Update von 3.5.4 auf 3.5.5 gerade mal wieder aktiviert - ich bin gespannt, ob das Update damit durchläuft.

 Bei mir lief es damit nicht durch.

----------

## slick

```
...

[ebuild   R   ] kde-base/kmail-3.5.5-r1  USE="arts crypt kdeenablefinal -debug -xinerama (-kdehiddenvisibility%*)" 0 kB

...

```

 (-kdehiddenvisibility%*) Häää? Wieso fliegt das wieder aus den ganzen KDE-Paketen raus? Könnte mich mal bitte jemand darüber aufklären.

----------

## astaecker

 *slick wrote:*   

>  (-kdehiddenvisibility%*) Häää? Wieso fliegt das wieder aus den ganzen KDE-Paketen raus? Könnte mich mal bitte jemand darüber aufklären.

 

Bisher wurde kdehiddenvisibility über die eclass kde als USE-Flag bei allen Paketen gesetzt. Dies wurde nun rückgängig gemacht und das USE-Flag explizit bei den Paketen gesetzt,  wo kdehiddenvisibility auch unterstützt wird.

----------

## Klaus Meier

 *arlsair wrote:*   

>  *slick wrote:*    (-kdehiddenvisibility%*) Häää? Wieso fliegt das wieder aus den ganzen KDE-Paketen raus? Könnte mich mal bitte jemand darüber aufklären. 
> 
> Bisher wurde kdehiddenvisibility über die eclass kde als USE-Flag bei allen Paketen gesetzt. Dies wurde nun rückgängig gemacht und das USE-Flag explizit bei den Paketen gesetzt,  wo kdehiddenvisibility auch unterstützt wird.

 

Also mit anderen Worten, es wird nur bei den Paketen deaktiviert, wo es nichts bewirkt hat? Man kann sich das neukompilieren als sparen?

----------

## astaecker

Ja

----------

## Klaus Meier

 *arlsair wrote:*   

> Ja

 Danke.

Dachte schon, es hätte irgendwelche Instabilitäten gegeben.

----------

## monade

 *arlsair wrote:*   

> 
> 
> Bisher wurde kdehiddenvisibility über die eclass kde als USE-Flag bei allen Paketen gesetzt. Dies wurde nun rückgängig gemacht und das USE-Flag explizit bei den Paketen gesetzt,  wo kdehiddenvisibility auch unterstützt wird.

 

Bisschen bescheuert, dass man dafür jetzt dutzende KDE-Pakete neu_kompilieren_ muss, wo sich doch eigentlich rein gar nichts für die Programme ändert. Man könnte meinen, dass sich sowas auch mit einem simplen Eintrag in einer Textdatei regeln lassen müsste.. Woher holen sich portage/eix/equery usw. eigentlich die Infos, mit welchen USE-Flags ein Paket kompiliert wurde? Aus /var/db/pkg/ oder? Es würde also theoretisch reichen /var/db/pkg/kate-gorie/paket/IUSE anzupassen?

----------

## Finswimmer

Zu jedem Paket wird das passende ebuild abgelegt, mit dem es kompiliert worden ist.

Wenn dieses und die neueste Version aus dem Portage variieren, wird es neu gebaut.

Tobi

----------

## UncleOwen

 *monade wrote:*   

> Woher holen sich portage/eix/equery usw. eigentlich die Infos, mit welchen USE-Flags ein Paket kompiliert wurde? Aus /var/db/pkg/ oder? Es würde also theoretisch reichen /var/db/pkg/kate-gorie/paket/IUSE anzupassen?

 

Genau.

 *Finswimmer wrote:*   

> Zu jedem Paket wird das passende ebuild abgelegt, mit dem es kompiliert worden ist.
> 
> Wenn dieses und die neueste Version aus dem Portage variieren, wird es neu gebaut.

 

Nope.

----------

## Klaus Meier

Aber wenn sich da sowieso nichts ändert, weder verbessert noch verschlechtert, dann hätte man mit dieser Änderung doch auch warten können, bis die nächste Version von KDE kommt. Man kompliliert es ja doch durch, weil es einfach nervt, wenn da beim Update immer 100 Dateien stehen, die man nicht neu übersetzen will.

Aber jetzt wegen dieser meiner Aussage bitte nicht wieder rückgängig machen.

----------

## monade

 *UncleOwen wrote:*   

>  *monade wrote:*   Woher holen sich portage/eix/equery usw. eigentlich die Infos, mit welchen USE-Flags ein Paket kompiliert wurde? Aus /var/db/pkg/ oder? Es würde also theoretisch reichen /var/db/pkg/kate-gorie/paket/IUSE anzupassen? 
> 
> Genau.

 

Hmm, dann ist das aber im moment REICHLICH ineffektiv. Es würde ja jetzt (in diesem speziellen Fall) ein einfaches "delete kdehiddenvisibility from /var/db/pkg/kate-gorie/paket/IUSE" für die Liste von betroffenen Paketen reichen und man würde tausende Stunden sinnlose Kompilierzeit weltweit sparen  :Wink: .

----------

## Finswimmer

 *UncleOwen wrote:*   

>  *monade wrote:*   Woher holen sich portage/eix/equery usw. eigentlich die Infos, mit welchen USE-Flags ein Paket kompiliert wurde? Aus /var/db/pkg/ oder? Es würde also theoretisch reichen /var/db/pkg/kate-gorie/paket/IUSE anzupassen? 
> 
> Genau.
> 
>  *Finswimmer wrote:*   Zu jedem Paket wird das passende ebuild abgelegt, mit dem es kompiliert worden ist.
> ...

 

Kannst du das ein bisschen genauer erklären?

Tobi

----------

## Klaus Meier

Also ich mache regelmäßig ein emerge --sync und ein emerge -uDN world. Und ich finde es total begeisternd, daß es irgendwelche esoterischen Befehle gibt, welche meinen Rechner wieder konsistent machen, ohne 10 Stunden absolut sinnfreies emergen.

Danke, das war ja wohl an Dummheit nicht mehr zu überbieten.

----------

## UncleOwen

 *Finswimmer wrote:*   

>  *UncleOwen wrote:*    *Finswimmer wrote:*   Zu jedem Paket wird das passende ebuild abgelegt, mit dem es kompiliert worden ist.
> 
> Wenn dieses und die neueste Version aus dem Portage variieren, wird es neu gebaut. 
> 
> Nope. 
> ...

 

Probiers doch einfach selber aus:

echo > /var/db/pkg/cat/pkg/pkg.ebuild; emerge -uDNp world

Portage will cat/pkg nicht neu bauen

echo > /var/db/pkg/cat/pkg/IUSE; emerge -uDNp world

Portage will cat/pkg neu bauen

----------

