| View previous topic :: View next topic |
| Author |
Message |
gt_amd64
Apprentice
Joined: 02 Dec 2004
Posts: 180
|
 Posted: Wed Jan 19, 2022 6:15 pm Post subject: [gelöst] x86_abi_32 Konflikte |
 |
|
Hallo,
ich hatte vor Jahren (war eine Empfehlung im englischen Forum, um emul-linux loszuwerden)
folgende Einträge in meine package.use aufgenommen
| Code: |
virtual/* abi_x86_32
media-libs/* abi_x86_32
media-sound/* abi_x86_32
x11-libs/* abi_x86_32
sys-libs/* abi_x86_32
dev-libs/* abi_x86_32
|
dadurch haben sich im laufe der Jahre viele weitere Anhängigkeiten ergeben, d.h. ich musste immer mal wieder bei einigen Paketen das abi_x86_32 USE-Flag setzen.
Nun würde ich gerne diese ganzen Abhängigkeiten von abi_x86_32 loswerden.
Ich habe also sämtliche abi_x86_32 Flags aus meiner package.use entfernt und dann versucht das System mit
| Code: |
emerge --deep --update --changed-use --changed-deps --with-bdeps=y @world
|
zu aktualisieren, aber das Ergebnis sind hunderte Konflikte wie dieser hier:
| Code: |
x11-libs/libXrender:0
(x11-libs/libXrender-0.9.10-r2:0/0::gentoo, ebuild scheduled for merge) USE="" ABI_X86="(64) -32 (-x32)" conflicts with
>=x11-libs/libXrender-0.9.8[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/libXrandr-1.5.2:0/0::gentoo, installed) USE="-doc" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXrender-0.9.8[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/pango-1.48.10-r1:0/0::gentoo, installed) USE="X introspection -debug -sysprof" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXrender-0.9.8[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/cairo-1.16.0-r5:0/0::gentoo, installed) USE="X glib opengl svg (-aqua) -debug (-gles2-only) -static-libs -utils -valgrind" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXrender-0.9.8[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/libXcursor-1.2.0:0/0::gentoo, installed) USE="-doc" ABI_X86="32 (64) (-x32)"
>=x11-libs/libXrender-0.9.8[abi_x86_32(-),abi_x86_64(-)] required by (x11-libs/libXft-2.3.4:0/0::gentoo, installed) USE="-doc" ABI_X86="32 (64) (-x32)"
|
Mein Profil ist "default/linux/amd64/17.1/desktop (stable)" und ich habe schon versucht auf "default/linux/amd64/17.1/no-multilib (stable)" umzustellen und gehofft das dadurch die Abhängikeiten automatisch entfernt werden, aber das hat nicht funktioniert - auch hier kommen extrem viele Konflikte.
Selbst wenn ich versuche Schrittweise abi_x86_32 Flags von einzelnen Pakten zu entfernen entstehen jede Menge Konflikte
Ich wäre sehr dankbar, wenn Jemand eine Idee hat, wie ich diese Konflikte mit möglichst wenig Aufwand lösen kann.
Last edited by gt_amd64 on Thu Jan 20, 2022 8:54 am; edited 1 time in total |
|
| Back to top |
|
 |
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Wed Jan 19, 2022 8:07 pm Post subject: |
|
|
Ich bin mir sicher, dass Du gleich noch ein paar bessere Tipps von Portage-Spezialisten bekommen wirst.
Wenn nicht, sollte ein
| Code: | | emerge --empty -av @world |
helfen. Vorher noch die World-Datei (/var/lib/portage/world) aufräumen - und hinterher überflüssige Pakete löschen mit
| Code: | | emerge --depclean -av |
Bevor Du das machst, solltest Du noch überlegen, ob Du weiterhin (rudimentäre) 32-Bit Unterstützung möchtest bzw. brauchst. Soweit ich weiß, gibt es ein paar Pakete wie Wine, die noch 32-Bit Support benötigen. Ich selbst habe schon vor Jahren auf "no-multilib" umgestellt - und habe nur noch 64-Bit Unterstützung.
Wenn Du auf "64-Bit only" wechseln willst, kannst Du
- entweder bei dem Profil "default/linux/amd64/17.1/desktop (stable)" bleiben - und nur den 32-Bit Support deaktivieren
- oder Du wechselst tatsächlich auf "default/linux/amd64/17.1/no-multilib (stable)"
Falls Du Methode 2 wählst, solltest Du zwei Dinge beachten:
- Ein Wechsel nach "no-mulitlib" ist einfach. Ein Wechsel zurück ist fast unmöglich. Wenn man sucht, findet man zwar Anleitungen für den Wechsel zurück - aber das ist auf jeden Fall anstrengend und NICHT empfehlenswert.
- Es gehen USE-Flags verloren (durch den Wechsel von "desktop" auf "basis"). Normalerweise kann man sich diese verloren gegangenen USE-Flags zusammensuchen aus dem Unterschied zwischen
vor und nach dem Wechsel des Profils - oder aber mit
| Code: | | emerge --update --deep --changed-use -pv @world |
nach dem Wechsel.
Dann kann man die fehlenden USE-Flags von Hand nach make.conf oder package.use eintragen.
Auf jeden Fall wünsche ich Dir viel Erfolg! |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1668
|
| Posted: Wed Jan 19, 2022 9:35 pm Post subject: |
|
|
hm, ich würde auch nicht empfehlen, ein no-multilib profil zu verwenden. Soweit ich weiß aktiviert das hauptsächlich die multilib use flags für gcc/glibc und keine ABI_X86=32 flags.
wie mike155 sagte, wird es nach dem abwählen dieser flags wohl recht kompliziert, das wieder rückgängig zu machen, falls man es doch mal braucht.
zu deinem aktuellen Problem bin ich mir auch nicht sicher, aber ich versuchs mal.
Der von dir gepostete ausschnitt deiner blocker sieht für mich so aus, als ob er gelöst werden können sollte. Alle Pakete die erwähnt sind brauchen ABI_X86=32 von x11-libs/libXrender nur, weil sie selbst ABI_X86=32 und von deinem emerge befehl neu gebaut werden sollen. Vermutlich werden diese pakete von anderen wieder gebraucht usw...
Ist irgendwo (ich glaube, über den Blockern steht das immer) was von "backtracking" zu lesen? evtl hilft das schon. Das kann dann aber auch wirklich lange dauern, bis portage zu einem Ergebnis kommt.
Bevor du das aber machst, würde ich noch ein normales update und danach emerge --deplean (wichtig!) machen, bevor du die abi_x86 flags entfernst. Da hat dann portage nur dieses eine zu berechnen und nicht noch die updates.
Das depclean solltest du machen, weil zb ein Paket mit abi_x86_32 gebaut ist, aber von keinen Paket mehr benötigt wird. Deswegen wird es vom emerge ... @world nicht zum neu bauen eingeplant wird und sein abi_x86_32 behält, und noch andere pakete mit diesem flag braucht, was zu einen block führen könnte.
Bei einem normalen update ist so eine situation eher selten, aber falls du einige programme deinstalliert hast, kann das vorkommen. Das wäre aber ein harter blocker, der so nicht gelöst werden kann von portage, deswegen sollte man es ausschließen.
Wenn das gemacht ist, dann nochmal die abi flags deaktivieren und backtrack einstellen.
Auch solltest du noch einmal kontrollieren, dass du kein abi_x86_32 in deiner package.use übersehen hast.
Viel Erfolg! |
|
| Back to top |
|
|
gt_amd64
Apprentice
Joined: 02 Dec 2004
Posts: 180
|
| Posted: Thu Jan 20, 2022 8:53 am Post subject: |
|
|
@mike155
vielen Dank!
--emptytree hat hier leider auch nicht geholfen - portage wollte über 1100 Pakete neu kompilieren und wollte bei einigen Paketen fehlende abi_x86_32 Flags haben. Nachdem ich diese Flags gesetzt habe, wollte portage wiederum weitere abi_x86_32 Flags haben usw. Dazu kam dann noch eine Meldung, die ich so auch noch nicht gesehen habe:
| Code: |
emerge: there are no ebuilds to satisfy "app-eselect/eselect-qtgraphicssystem".
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
emerge: there are no ebuilds to satisfy "sys-libs/compiler-rt-sanitizers:6.0.1".
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
emerge: there are no ebuilds to satisfy "sys-libs/compiler-rt:6.0.1".
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
|
Scheinbar sind in meiner "world" Pakete vorhanden, die nicht mehr existieren aber bei --depclean nicht angezeigt werden...
wenn Jemand einen Tipp hat, wie man die world-Datei automatisch bereinigen kann, wäre das hilfreich, falls da noch mehr Einträge von nicht mehr existierenden Paketen vorhanden sind.
Der Hinweis das no-multilib unumkehrbar ist war sehr hilfreich - das habe ich also gelassen.
Das Stichwort "wine" hat mir dann später noch geholfen...
@Christian99
auch --backtrack=10 hat leider nicht weitergeholfen.
Bei den Abhängigkeiten ist mir immer wieder wine-vanilla aufgefallen. Mein letzter verzweifelter Versuch war also
| Code: | | emerge -C wine-vanilla |
ein
| Code: | | emerge --deep --newuse --update --changed-use --changed-deps --with-bdeps=y @world -pv |
hat nun keine Fehlermeldungen mehr angezeigt und es sollen "nur" 170 Pakete aktualisiert werden.
Das läuft gerade und wird noch einige Stunden dauern.
Danach werde ich dann versuchen wieder wine-vanilla zu installieren und hoffe das sich die Zahl der benötigten abi_x86_32 Flags deutlich reduziert hat.
Vielen Dank für eure Hilfe! |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1668
|
| Posted: Thu Jan 20, 2022 10:27 am Post subject: |
|
|
ah, ok. wenn wine mit abi_x86_32 installiert war, ist es klar, dass es nicht geht.
das braucht ja noch pakete mit abi_x86_32 und wenn du bei denen die flags deaktivierst ist es ein konflikt.
Ich hatte dich so verstanden, dass du alle abi_x86_32 flags deaktiviert hast. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Thu Jan 20, 2022 10:44 am Post subject: |
|
|
Wenn 'emerge --emptytree' nicht funktioniert, ist das ein deutlicher Hinweis auf Probleme in den Konfigurationsdateien.
Häufige Ursache sind überzählige Einträge in der World-Datei (var/lib/portage/world).
Du kannst diese Datei in einen Editor laden und dann aufräumen.
In der World-Datei sollten nur die Pakete stehen, die Du wirklich installiert haben willst, also. z.B. app-office/libreoffice.
NICHT enthalten in der World Datei sollten sein:
- Alle Pakete, die über @system installiert werden, also z.B. gcc, glibc, usw.
- Alle Pakete, die nur installiert sind, weil sie von anderen Paketen benötigt werden. Typisches Beispiel: Libraries. Ein anderes Beispiel wäre clang/llvm wenn es nur installiert ist, weil Du Firefox installierst hast und Firefox clang/llvm reingezogen hast. Wenn Du stattdessen clang/llvm aktiv nutzt, sollte auch clang/llvm in der World-Datei stehen.
Hier ein paar Tipps:
- Die World-Datei sollte so klein wie möglich sein!
- Libraries gehören typischerweise nicht rein
- Pakete mit Versionsnummer gehören typischerweise nicht rein - außer Du willst, dass eine bestimmte Version installiert ist. Ein Beispiel wäre: Du möchtest, dass GCC 9 installiert ist, weil Du damit entwickelst.
- Wenn Du etwas löschst, hinterher 'emerge --depclean -av' aufrufen.
- Alle Pakete, die Du entfernen kannst, ohne dass ein "emerge --depclean" hinterher etwas löschen würde, solltest Du löschen.
- In Zukunft bei emerge immer die Option "--oneshot" verwenden, wenn Du Pakete beim Troubleshooting installierst. Sonst wird das Paket in die World-Datei geschrieben.
- Keine Angst davor, zu viel zu löschen. Wenn Du zu viel gelöscht haben solltest, kannst Du die Pakete ja hinterher mit emerge wieder installieren. Gentoo funktioniert auch mit einer leeren World-Datei - das ist der Grundzustand.
|
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1668
|
| Posted: Thu Jan 20, 2022 11:32 am Post subject: |
|
|
| gt_amd64 wrote: |
Scheinbar sind in meiner "world" Pakete vorhanden, die nicht mehr existieren aber bei --depclean nicht angezeigt werden...
wenn Jemand einen Tipp hat, wie man die world-Datei automatisch bereinigen kann, wäre das hilfreich, falls da noch mehr Einträge von nicht mehr existierenden Paketen vorhanden sind.
|
emaint world {check,fix}
gibt es dafür
sys-libs/compiler-rt:6.0.1
compiler-rt gibt es zwar noch, aber in deiner world datei scheint noch der slot 6.0.1 mit drin zu stehen, den es nicht mehr gibt.
Davon abgesehen sollte sowas wie compiler-rt bei den allermeisten leuten nicht in der world datei stehn.
vermutlich hast du da irgendwann mal --oneshot vergessen.
Da das auch mir recht häufig passiert ist, habe ich inzwischen --oneshot in den EMERGE_DEFAULT_OPTS stehen, und mache explizit emerge --select, wenn ich etwas installieren will, das da bleiben soll.
Ich würde dir deswegen zusätzlich zu emaint noch empfehlen, deine world datei mal per hand durchzugehen, und Sachen, die du nicht explizit direkt brauchst daraus zu entfernen. |
|
| Back to top |
|
|
gt_amd64
Apprentice
Joined: 02 Dec 2004
Posts: 180
|
| Posted: Thu Jan 20, 2022 6:22 pm Post subject: |
|
|
@Christian99
Ich hatte wie geschrieben sämtliche x86_abi_32 Einträge per search&replace (also wurde da auch Nichts übersehen) aus meiner .use entfernt. Dennoch hat das bereits installierte wine-vanilla Paket offensichtlich diese Abhängigkeits-Schleife ausgelöst. wine-vanilla benötigt ein -x86_abi_32 in der .use, um nicht wieder diese ganzen Abhängigkeiten auszulösen. Da wine 7.0 nun x64 vollständig unterstützen soll wird das vermutlich für meine Zwecke reichen, da ich wine hauptsächlich für Irfanview benötige und das habe ich eben getestet - funktioniert problemlos. Leider habe ich in den ganzen Jahren, in denen ich von Windows weg bin noch keinen brauchbaren Linux-Ersatz für Irfanview gefunden :/
emaint ist irgendwie an mir vorbeigegangen - das scheint recht nützlich zu sein - man lernt eben nie aus.
@mike155
ich werde in der Tat wohl mal meine world Datei aufräumen müssen - da hat sich in den Jahren so einiges angesammelt.
Nochmals Danke - mein System ist jetzt endlich bereinigt von x86_abi_32  |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1668
|
| Posted: Fri Jan 21, 2022 10:09 am Post subject: |
|
|
| ja, du hast recht. wine hat abi_x86_32 per default aktiviert. Das scheint neu zu sein, ist mir noch nicht aufgefallen. Und irgendwie ist das auch unschön... |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5183
|
| Posted: Fri Jan 21, 2022 2:39 pm Post subject: |
|
|
Aktuell braucht wine 32 bit binaries damit man via wine 32bit Windows Programme starten kann.
Mit Wine 7.0 wurden ein neues WoW64 Architektur eingführt mit der man 32 Bit Code in einem 64Bit Host Prozess laufen lassen kann.
Wobei die Implementierung noch nicht komplett ist
| https://www.winehq.org/announce/7.0 wrote: |
*** WoW64
- The 64-bit Windows-on-Windows (WoW64) architecture is implemented, and
supports running a 32-bit Windows application inside a 64-bit Unix host
process, using thunks to map 32-bit NT system calls to the 64-bit NTDLL.
- WoW64 thunks are implemented for most Unix libraries, enabling a 32-bit PE
module to call a 64-bit Unix library. Once the remaining modules are
converted to PE, this will make it possible to run 32-bit applications
without installing 32-bit Unix libraries.
|
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
