# [multilib] ABI_x86 (résolu)

## Kevin57

Bonjour,

Je viens pour une petite question de MAJ. Je vois qu'emerge veut me faire ajouter une option "ABI_x86=32 64" (apparemment pour la gestion du multilib). Cette option bloque les paquets du type app-emulation/emul-linux-x86-xlibs et je vois sur les forums anglais (https://forums.gentoo.org/viewtopic-p-7266638.html) que ça peut poser problème pour des paquets comme wine ou skype, quelqu'un a fait les tests et peut me dire ce qu'il en est? J'ai peur de faire la MAJ et de ne plus pouvoir faire marcher ces paquets jusqu'à ce qu'ils soient mis à jour à leur tour. 

Merci d'avance!

Kevin

----------

## xaviermiller

Hello,

Je vais regarder l'un de ces jours  :Wink: 

----------

## Kevin57

En attendant, je préfère ne pas faire la MAJ, j'utilise wine assez régulièrement (bien obligé de contrôler l'aspect des documents sous Word dans mon métier) donc ce serait embêtant que la MAJ casse wine...

----------

## netfab

La version 1.5.25 de wine est censée gérer cette nouvelle variable ABI_X86 (qui remplace alors les USE win32 et win64).

J'ai essayé d'y passer, je ne m'en suis pas sorti, mais je suis en stable. Donc pour le moment j'attend de voir.

----------

## Kevin57

En effet, je l'ai déjà installée et je ne m'étais pas rendu compte qu'elle incluait cette option. Du coup, c'est sûr que wine continuera de marcher si je fais la MAJ?

----------

## netfab

Si wine compile et s'installe correctement, il n'y a pas de raison qu'il ne fonctionne pas, c'est exactement la même version qu'aurapavant.

C'est simplement la gestion du multilib côté gentoo qui est modifiée. Tu es en ~arch ?

----------

## Kevin57

Oui, je suis en ~amd64 (c'est écrit dans ma signature  :Very Happy:  ). Je viens de lancer la MAJ, d'autant que je viens de voir que le ABI_x86=32 semble juste bloquer <=app-emulation/emul-linux-x86-xlibs-20130224 et que la MAJ inclut, justement, app-emulation/emul-linux-x86-xlibs-20130224-r1, donc peut-être que les deux pourront cohabiter le temps que tout l'arbre s'adapte. Cela dit, une news aurait été intéressante avant de faire un changement...

----------

## guilc

C'est "super" cette nouveauté : maintenant les lilbs 32bits sont assurées partiellement par les ebuids de l'arbre de portage et plus directement par le paquet emulm-linux-x86-xlibs.

Par contre du coup, il faut se taper tout un stock de USE en plus, mon package.use devient magnifiquement lisible  :Surprised: 

```
media-libs/fontconfig abi_x86_32

media-libs/freetype abi_x86_32

dev-libs/libpthread-stubs abi_x86_32

x11-libs/libX11 abi_x86_32

x11-libs/libXau abi_x86_32

x11-libs/libxcb abi_x86_32

x11-libs/libXdmcp abi_x86_32

x11-libs/libXext abi_x86_32

x11-libs/libXrender abi_x86_32

x11-proto/xproto abi_x86_32

x11-proto/xextproto abi_x86_32

x11-proto/xf86bigfontproto abi_x86_32

x11-proto/inputproto abi_x86_32

x11-proto/renderproto abi_x86_32

x11-proto/kbproto abi_x86_32

x11-proto/xcb-proto abi_x86_32

x11-libs/libICE abi_x86_32

x11-libs/libSM abi_x86_32

x11-libs/libXdamage abi_x86_32

x11-libs/libXfixes abi_x86_32

x11-libs/libXxf86vm abi_x86_32

x11-libs/libXinerama abi_x86_32

x11-libs/libXcomposite abi_x86_32

x11-libs/libXScrnSaver abi_x86_32

x11-libs/libXp abi_x86_32

x11-libs/libXv abi_x86_32

x11-libs/libXpm abi_x86_32

x11-libs/libXxf86dga abi_x86_32

x11-libs/libXt abi_x86_32

x11-libs/libXcursor abi_x86_32

x11-libs/libXft abi_x86_32

x11-libs/libXaw abi_x86_32

x11-libs/libXtst abi_x86_32

x11-libs/libpciaccess abi_x86_32

x11-libs/libXrandr abi_x86_32

x11-libs/libvdpau abi_x86_32

x11-libs/libXvMC abi_x86_32

x11-libs/libXi abi_x86_32

x11-libs/libXmu abi_x86_32

x11-proto/damageproto abi_x86_32

x11-proto/fixesproto abi_x86_32

x11-proto/xf86vidmodeproto abi_x86_32

x11-proto/randrproto abi_x86_32

x11-proto/xf86dgaproto abi_x86_32

x11-proto/xineramaproto abi_x86_32

x11-proto/scrnsaverproto abi_x86_32

x11-proto/printproto abi_x86_32

x11-proto/recordproto abi_x86_32

x11-proto/videoproto abi_x86_32

x11-proto/compositeproto abi_x86_32
```

----------

## xaviermiller

Ouais... je suis relativement content : enfin partis ces blobs pas à jour par rapport à ~arch.

Pour les use, groupe-les dans un fichier du genre /etc/portage/package.use/multilib  :Wink: 

----------

## netfab

 *guilc wrote:*   

> 
> 
> Par contre du coup, il faut se taper tout un stock de USE en plus, mon package.use devient magnifiquement lisible 
> 
> 

 

Un :

```

ABI_X86="64 32"

```

dans le make.conf ne suffit pas ?

----------

## xaviermiller

C'est ce que le topic pointé par Kevin propose.

Mais dans ce cas, ne va-t-on pas tout compiler en 32 bits au lieu de ne prendre que le nécessaire ?

Vivement une doc / news !

----------

## Kevin57

Personnellement, j'ai juste ajouté ABI_X86="64 32" dans mon make.conf et tout semble bien marcher. Mais du coup, en effet, tout doit être compilé "en double" je suppose, mais ça ne me dérange pas, j'aime autant en avoir un peu trop que pas assez...

----------

## netfab

 *XavierMiller wrote:*   

> Mais dans ce cas, ne va-t-on pas tout compiler en 32 bits au lieu de ne prendre que le nécessaire ?
> 
> 

 

Ah oui je n'avais pas vu çà comme çà. Je verrai en temps voulu comment je gérerai la chose, mais je pense que j'activerai par défaut la compilation 32 bits, et si besoin je redéfinirai la variable  ABI_X86 (en utilisant les fichier package.env) au cas par cas pour les paquets qui prennent du temps à compiler et dont je n'ai pas besoin (qt par exemple).

----------

## xaviermiller

ouais, ou un package.use ;-

----------

## xaviermiller

Coucou,

Avec une tétrachiée d'entrées dans un package.use, c'est passé comme une lettre à la poste.

En gros, j'ai récupéré la sortie d'erreur d'emerge et tout injecté dans un package.use spécifique à multilib

----------

## guilc

Anéfé, pareil ici.

Au passage, je package dans mon overlay 2 applis binaires 32bits, bah ça me permet de réduire la voilure des libs 32bits au moins pour l'une d'entre elles et de dépendre seulement sur les libs X11 vraiment nécessaires au lieu de l'intégralité de emul-linux-x86-xlibs  :Wink: 

https://gentoo.xwing.info/media-gfx/AfterShotPro/AfterShotPro-1.1.1.10.ebuild

https://gentoo.xwing.info/Documentation/package.use

Donc c'est pas mal, même si c'est quand même un peu lourd à utiliser  :Surprised: 

----------

## xaviermiller

Bah, j'imagine que les emul-linux disparaîtront progressivement pour donner place aux vraies dépendances 32 bits.

Je me réjouis que ces blobs binaires disparaissent enfin !

----------

## guilc

PFFFFFFF, bon, là ça m'énerve : https://bugs.gentoo.org/show_bug.cgi?id=461608

```
# Markos Chandras <hwoarang@gentoo.org> (13 Mar 2013)

# Mask because breaking updates out of the blue is bad

# See 461608. Unmask it only if you want abi_x86_32

# which means you have ABI_X86=32 set in your make.conf

=app-emulation/emul-linux-x86-xlibs-20130224-r1
```

Le coup du j'avance et je recule, c'est juste pénible   :Confused: 

Sinon, les blobs franchement, ça me gène pas : je mets ces packages uniquement pour 1 programme binaire propriétaire que j'utilise alors bon. Je dirais même au contraire, comme ça ales trucs binaires restent dans leur coin sans impacter le reste de mon système (qui n'est multilib QUE pour ça)

----------

## Kevin57

Xavier : je n'arrive pas à voir la différence entre ajouter les paquets dans le package.use et le faire comme je l'ai fait moi (donc direct dans le make.conf) si c'est pour, de toute manière, mettre tous les paquets dans le package.use. Tu peux m'expliquer?

----------

## xaviermiller

La différence est que je n'ai mis que les paquets nécessaires, et pas demandé que tous les paquets proposant la double ABI se compilent aussi en 32 bits.

Au final, je n'ai qu'une trentaine de paquets, et pas une centaine (au pif).

----------

## Kevin57

Ah d'accord. Je demandais parce que finalement (en tout cas aujourd'hui), j'ai eu autant de paquets à recompiler en modifiant le make.conf que si j'avais édité le package.use (à un ou deux près, peut-être), donc je ne voyais pas la différence. Mais elle risque d'être visible quand tous les paquets auront été adaptés, c'est ça?

----------

## xaviermiller

ouiche  :Smile: 

----------

## Kevin57

Bon, ben pour rester fidèle à moi-même : j'improviserai quand j'en aurai marre!   :Very Happy: 

----------

## xaviermiller

C'est la procession d'Echternach ce truc !   :Sad: 

J'ai démasqué l'ebuild emul-*, mais vu le bug je crains qu'on ne revienne en arrière vers les blobs binaires avant qu'on ne fixe définitivement les bricolages de l'overlay multilib...

----------

## blietaer

 *netfab wrote:*   

> 
> 
> Un :
> 
> ```
> ...

 

Nope: du coup il y a une ch*!#ée de ebuilds (29!) qui bloquent au emerge -avDNut @world suivant...    :Shocked: 

Cela disparait si je laisse uniquement:  

```

ABI_X86="64"

```

Mais bcp de ebuils (libx11) se font remoudre en "-32" du coup, ...pas certain que ce soit ce que je veuilles.    :Rolling Eyes: 

Donc il faut placer le:

```

ABI_X86="64 32"

```

et taper le USE abi_x86_32 dans make.conf ?!!!    :Question: 

Edit: ah, tiens, non cela ne guéri rien: tjrs 29 ebuilds bloquants...   :Evil or Very Mad: 

----------

## blietaer

 *XavierMiller wrote:*   

> En gros, j'ai récupéré la sortie d'erreur d'emerge et tout injecté dans un package.use spécifique à multilib

 

Suis à 2 doigts de le faire, mais j'ai (bcp) de mal à croire que ce soit la procédure de base....?!

D'ailleurs elle est où cette procédure?

pas de eselect news à ce propos?!

----------

## xaviermiller

Pas de news, et un bug ouvert, qui montre que les devs ne sont pas d'accord entre eux (complètement glucose...)

----------

## blietaer

Moi ceci m'a sauvé le lundi:

https://forums.gentoo.org/viewtopic-t-953900-highlight-.html

C'est pas complètement inintéressant au point de vue compression analogique, un peu soft au point de vue des échantillonnages.

----------

## xaviermiller

Yep, je pense que tout le monde (fr) suit ce sujet, et celui (déjà cité) que tu mentionnes  :Wink: 

----------

