Gentoo: Maskierte Pakete und ihre Abhängigkeiten

[Turrican]

Hallo!

Es gibt da ein kleines Problem, auf das ich schon desöfteren gestoßen bin.
Es ist ja nun so, dass es unter Gentoo "leicht" maskierte Pakete gibt (die man einfach mit ~x86 installiert, das ist der Großteil) und eklig "schwer" maskierte Pakete, wo auch kein ~x86 hilft, sondern nur das direkte:
emerge /usr/portage/.../blabla.ebuild

Beispiel KDE: Ein

ACCEPT_KEYWORDS=~x86 emerge -p kde
spuckt mir

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] kde-base/kde-3.1.4
aus, obwohl es ja schon KDE 3.2 Beta im Portage gibt.
Wie bekomme ich das nun installiert, wenn dessen Abhängigkeiten (kdebase, kdelibs, ...) ebenfalls "schwer" maskiert sind?
Ich hoffe, es wird deutlich was ich meine - ich fange also an mit:

ACCEPT_KEYWORDS=~x86 emerge -p /usr/portage/kde-base/kde/kde-3.2.0_beta1.ebuild
und erhalte:

These are the packages that I would merge, in order:

Calculating dependencies \
!!! all ebuilds that could satisfy "~kde-base/kdeutils-3.2.0_beta1" have been masked.
!!! (dependency required by "kde-base/kde-3.2.0_beta1" [ebuild])

!!! Error calculating dependencies. Please correct.
Dann denke ich mir, ja gut, wenn du das unbedingt willst, dann also:

ACCEPT_KEYWORDS=~x86 emerge -p /usr/portage/kde-base/kdeutils/kdeutils-3.2.0_beta1.ebuild
Antwort:

These are the packages that I would merge, in order:

Calculating dependencies \
!!! all ebuilds that could satisfy "=kde-base/kdebase-3.2.0_beta1" have been masked.
!!! (dependency required by "kde-base/kdeutils-3.2.0_beta1" [ebuild])

!!! Error calculating dependencies. Please correct.
Hm. Toll, einmal im Kreis gedreht.
Und jetzt? :(

[Komet]

Du kannst die betreffenden Pakete in /usr/portage/profiles/package.mask auskommentieren, dann sind sie nicht mehr maskiert, jedenfalls bis zum nächsten emerge sync...

[Turrican]

Cool, danke! :)

[ZuXeZ]

unmasken/masken wird in /etc/portage/package.unmask bzw /etc/portage/package.mask erledigt...und dann klapps auch bis nach dem nächsten emergen ;)
syntax is die selbe wie in /usr/portage/profiles/package.mask

[Komet]

nanu, so'n Ordner bzw die Files hab ich gar nicht... Werden wohl nicht standardmäßig angelegt...

[ZuXeZ]

joa bei mir auch net, hab das aber mal vor nen paar monaten bei nem emerge portage am ende gelesen ;)

[Komet]

Hab ich jetzt auch angelegt, danke noch für den Tip :)

[ZuXeZ]

keine ursache, dafür is das forum schließlich da

[DarkSorcerer]

Sollte KDE 3.2 nicht auch im unstable Zweig sein? Sprich "Accept_Keywords=~arch"

[ZuXeZ]

Sollte KDE 3.2 nicht auch im unstable Zweig sein? Sprich "Accept_Keywords=~arch"

ist sie schon, aber trotzdem masked...unmasken und emergen und warten und nutzen :D
meine is heut früh fertig geowrden -> erster start: segfault von kdehotkeys ;)

[Leberwurstsaft]

erster start: segfault von kdehotkeys
Zu aggressive CFLAGS ? KDE 3.2 Beta 1 läuft bei mir problemlos.

[ZuXeZ]

nöö eigentlich nich...nur athlon-tbird o3 mmx 3dnow pipe und omit-frame-pointer ;)
naja egal hb das hotkeyteil ausgeschalten...brauch ich eh nich :)

[DarkSorcerer]

Noch was zu maskierten Paketen:
http://forums.gentoo.org/viewtopic.php?t=33534

[Stanislaus]

Wo Ihr gerade beim Thema seid misch ich mich doch auch noch ein.
Hätte da mal 2 Fragen:
1. Was bedeutet "arch"? Hab in meiner make.conf bei ACCEPT_KEYWORDS x86 stehen. (tilde davor ist maskiert, soweit ist mir das klar) Aber was ist arch.
Ich frage wegen dieser Aussage:

Sollte KDE 3.2 nicht auch im unstable Zweig sein? Sprich "Accept_Keywords=~arch"
was hat unstable mit arch zu tun?
2. omit-frame-pointer

nur athlon-tbird o3 mmx 3dnow pipe und omit-frame-pointer
Wenn ich mich recht entsinne bewirkt omit-frame-pointer doch, daß zusätliche debug Informationen mit einkompiliert werden. Allerdings mit dem Effekt, daß die Kompilate größer und langsamer werden. Oder irre ich mich da?
Und warum haben etliche Leute diese Option im Einsatz?

@Topic: Bei wenigen Abhängigkeiten editiere ich i.d.R das entsprechende ebuild und mache aus dem "~x86" einfach ein "x86" und gut is.

Bis neulich ...

[ZuXeZ]

wenn ich mich recht entsinne bewirkt omit-frame-pointer doch, daß zusätliche debug Informationen mit einkompiliert werden. Allerdings mit dem Effekt, daß die Kompilate größer und langsamer werden. Oder irre ich mich da? Und warum haben etliche Leute diese Option im Einsatz?

stimmt so nich...omit steht für weglassen...also frame-pointer weglassen ;)

[Turrican]

@Stanislaus:

"arch" bedeutet einfach Architektur, also in deinem Fall "x86".
Es gibt ja noch PPC, 64-Bit und so Zeugs und "arch" ist da einfach der Oberbegriff.
Man möge mich korrigieren, wenn ich falsch liegen sollte.

[Stanislaus]

Juhten Abend!

@ZuXeZ: Jetzt fällt es mir wie Schuppen von den Augen :D omit = vermeiden hätt ich auch selbst drauf kommen können. Aber wofür gibts euch ;)
Stimmt es denn wenigstens, daß die frame-pointers Geschichte Einfluss auf die debug Informationen hat?

@Turrican: So weit so gut. Aber eben weil es ja ppc, x86 etc... gibt stellt sich mir die Frage nach dem Sinn von arch. Scheint ja nicht plattformspezifisch zu sein aber was dann und wozu? Sind damit die Pakete gekennzeichnet, die auf allen unterstützten Plattformen laufen?

Bis neulich ...

[Stage]

-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one.
This avoids the instructions to save, set up and restore frame pointers; it also
makes an extra register available in many functions. It also makes debugging
impossible on some machines.

On some machines, such as the VAX, this flag has no effect, because the standard
calling sequence automatically handles the frame pointer and nothing is saved by
pretending it doesn't exist. The machine-description macro
"FRAME_POINTER_REQUIRED" controls whether a target machine supports this flag.

Enabled at levels -O, -O2, -O3, -Os.

d.h kann man auch weglassen, wenn man die Optimierungen aktiviert hat

[Turrican]

@Stanislaus:

Ich bin mir jetzt wirklich nicht mehr sicher, aber dennoch glaube ich nicht, dass "arch" ein gültiges Schlüsselwort ist. Eher so eine Art Platzhalter: "arch" = "Du, User, schreibe hierhin, welche Architektur du hast, weil ich, Gentoo, die wissen muss"
Oder? :confused:

[Stage]

turrican hat teilweise recht
auszug aus make.conf

....A special form has been added that
# indicates packages and revisions that are expected to work, but have not yet
# been approved for the stable set. '~arch' is a superset of 'arch' which
# includes the unstable, in testing, packages.

[ZuXeZ]

Original geschrieben von Turrican
@Stanislaus:

Ich bin mir jetzt wirklich nicht mehr sicher, aber dennoch glaube ich nicht, dass "arch" ein gültiges Schlüsselwort ist. Eher so eine Art Platzhalter: "arch" = "Du, User, schreibe hierhin, welche Architektur du hast, weil ich, Gentoo, die wissen muss"
Oder? :confused:

so seh ich das auch, man schreibt seine rechnerarchitektur da einfach rein...in manchen beuild steht ja auch sowas in der art von:

glibc unstable KEYWORDS="-* ~x86 ~sparc ~amd64 ~hppa ~alpha"
glibc stable KEYWORDS="x86 ppc sparc alpha -hppa ~arm mips ia64"

danach sucht er halt beim installieren aus was er installieren/updaten wird

[Stanislaus]

Moin, moin!

Oh man, ich sollte vielleicht in Zukunft die Hinweise der make.conf mal genauer lesen.
Auf jeden Fall besten Dank für die Aufklärung.

Bis neulich ...

[Turrican]

Nochmal was zu -fomit-frame-pointer und

Original geschrieben von Stage
d.h kann man auch weglassen, wenn man die Optimierungen aktiviert hat

Über die Gentoo-Foren bin ich auf folgenden Tipp gestoßen. Wenn man sich z.B. mal schnell ein Hallo Welt-Programm in C schreibt (oder auch ein Programm, was gar nichts macht), so kann man mit:
gcc -v -Q -O3 test.c

sich ansehen, welche Flags tatsächlich durch -O3 benutzt werden.
Wenn ich es richtig verstanden habe, ist -O3 nur eine Art Meta-Optimierung, die intern zu den echten Optimierungen ("-fblablabla") übersetzt wird. Es wird halt einem Tipparbeit abgenommen.
Soweit stimmt das mit dem überein, was Stage gesagt hat.
Aber wenn ich nun diesen Test mache, bekomme ich folgendes:

options enabled: -feliminate-unused-debug-types -fdefer-pop
-foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks
-fexpensive-optimizations -fthread-jumps -fstrength-reduce -fpeephole
-fforce-mem -ffunction-cse -fkeep-static-consts -fcaller-saves
-fpcc-struct-return -fgcse -fgcse-lm -fgcse-sm -frerun-cse-after-loop
-frerun-loop-opt -fdelete-null-pointer-checks -fschedule-insns2
-fsched-interblock -fsched-spec -fbranch-count-reg -freorder-blocks
-frename-registers -fcprop-registers -fcommon -fgnu-linker -fregmove
-foptimize-register-move -fargument-alias -fstrict-aliasing
-fmerge-constants -fident -fpeephole2 -fguess-branch-probability
-fmath-errno -ftrapping-math -fno-stack-protector -m80387 -mhard-float
-mno-soft-float -mieee-fp -mfp-ret-in-387 -mcpu=pentiumpro -march=i386

Entweder bin ich blind, oder da steht wirklich nichts von -fomit-frame-pointer?!
Wird das doch nicht durch -O3 aktiviert?
Sollte ich es in meine /etc/make.conf reinpacken, ich meine, bringt das viel?
Würde sich gar ein emerge -e world lohnen?!!

Meine Flags sehen momentan so aus:
CFLAGS="-O3 -march=athlon-tbird -funroll-loops -pipe"
CXXFLAGS="${CFLAGS}"