[gentoo-user] ABI_X86=

[gentoo-user] ABI_X86=

[James]

Hello,

> 
>
so on one system, I run a amd default profile::
[1] default/linux/amd64/13.0 

A while back I tested converting the system to only 64 bit libs, then
changed it back, so I thought. Several updated where fine. Now quite a few
packages
are complaining [A]. So looking around is this the correct fix, just
add this line to make.conf::

ABI_X86="32 64"

A better or more appropriate fix? The system 'emerge -UDNvp @world shows
these many conflicts now below are a few. I run a minimal desktop (lxde).

James


[A] virtual/libiconv:0

  (virtual/libiconv-0-r2:0/0::gentoo, ebuild scheduled for merge) conflicts with
    >=virtual/libiconv-0-r1[abi_x86_32(-),abi_x86_64(-)] required by
(dev-libs/glib-2.46.2-r1:2/2::gentoo, installed)


x11-libs/libXv:0

  (x11-libs/libXv-1.0.10:0/0::gentoo, ebuild scheduled for merge) conflicts with
    >=x11-libs/libXv-1.0.10[abi_x86_32(-),abi_x86_64(-)] required by
(x11-libs/libXvMC-1.0.9:0/0::gentoo, installed)

  >=x11-libs/libX11-1.6.2[abi_x86_32(-)] required by
(dev-util/android-studio-1.2.2.0.141.1980579:0/0::gentoo, installed)

[gentoo-user] Solved: ABI_X86=

[James]

James <wireless <at> tampabay.rr.com> writes:


> so on one system, I run a amd default profile::
> [1] default/linux/amd64/13.0 

> A while back I tested converting the system to only 64 bit libs, then
> changed it back, so I thought. Several updated where fine. Now quite a few
> packages are complaining [A]. So looking around is this the correct fix,  
> just add this line to make.conf::

> ABI_X86="32 64"

Well this just worked fine, but, I'm curious if this (ABI_X86="32 64")
setting in make.conf should be part of any selected profile for amd_64 ?


James

Re: [gentoo-user] Solved: ABI_X86=

[Alan McKinnon]

On 29/02/2016 14:36, James wrote:
> James <wireless <at> tampabay.rr.com> writes:
> 
> 
>> so on one system, I run a amd default profile::
>> [1] default/linux/amd64/13.0 
> 
>> A while back I tested converting the system to only 64 bit libs, then
>> changed it back, so I thought. Several updated where fine. Now quite a few
>> packages are complaining [A]. So looking around is this the correct fix,  
>> just add this line to make.conf::
> 
>> ABI_X86="32 64"
> 
> Well this just worked fine, but, I'm curious if this (ABI_X86="32 64")
> setting in make.conf should be part of any selected profile for amd_64 ?


It's not in any profiles, you have to set it manually. Doing it globally
like you did compiles 32 and 64 bit versions of everything, that will
make most gentooers whinge mightily


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Solved: ABI_X86=

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> >> ABI_X86="32 64"

> > Well this just worked fine, but, I'm curious if this (ABI_X86="32 64")
> > setting in make.conf should be part of any selected profile for amd_64 ?

> It's not in any profiles, you have to set it manually. Doing it globally
> like you did compiles 32 and 64 bit versions of everything, that will
> make most gentooers whinge mightily


Is there a provision (mechanism) to have this autoset, if a package dependency
call for it? The system was fine for a quite a while until I forced it to
only install 64 bit libs. What's the proper (auto) fix, as I do not remember
having to have all of these 32 bit libs before, only a few?


suggestions?

James

Re: [gentoo-user] Re: Solved: ABI_X86=

[Alan McKinnon]

On 29/02/2016 18:59, James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> 
> 
>>>> ABI_X86="32 64"
> 
>>> Well this just worked fine, but, I'm curious if this (ABI_X86="32 64")
>>> setting in make.conf should be part of any selected profile for amd_64 ?
> 
>> It's not in any profiles, you have to set it manually. Doing it globally
>> like you did compiles 32 and 64 bit versions of everything, that will
>> make most gentooers whinge mightily
> 
> 
> Is there a provision (mechanism) to have this autoset, if a package dependency
> call for it? The system was fine for a quite a while until I forced it to
> only install 64 bit libs. What's the proper (auto) fix, as I do not remember
> having to have all of these 32 bit libs before, only a few?


There isn't an auto-fix to my knowledge, other than setting the flag
globally in make.conf. At heart ABI_X86 is a USE flag and follows all
the rules of USE flags - you set them globally or per-package.

Do you have an automagic method to enable mysql support for postfix in
one step that will set all needed USE? Mo? Well, there isn't one for
ABX_X86 either. You set the flag on for the 32 bit apps you have, and
follow the chain of incompatible USE all the way to the end. It's a
major pain in the butt.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Solved: ABI_X86=

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

On Monday 29 Feb 2016 23:07:12 Alan McKinnon wrote:
> On 29/02/2016 18:59, James wrote:
> > Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> >>>> ABI_X86="32 64"
> >>> 
> >>> Well this just worked fine, but, I'm curious if this (ABI_X86="32 64")
> >>> setting in make.conf should be part of any selected profile for amd_64 ?
> >> 
> >> It's not in any profiles, you have to set it manually. Doing it globally
> >> like you did compiles 32 and 64 bit versions of everything, that will
> >> make most gentooers whinge mightily
> > 
> > Is there a provision (mechanism) to have this autoset, if a package
> > dependency call for it? The system was fine for a quite a while until I
> > forced it to only install 64 bit libs. What's the proper (auto) fix, as I
> > do not remember having to have all of these 32 bit libs before, only a
> > few?
> 
> There isn't an auto-fix to my knowledge, other than setting the flag
> globally in make.conf. At heart ABI_X86 is a USE flag and follows all
> the rules of USE flags - you set them globally or per-package.
> 
> Do you have an automagic method to enable mysql support for postfix in
> one step that will set all needed USE? Mo? Well, there isn't one for
> ABX_X86 either. You set the flag on for the 32 bit apps you have, and
> follow the chain of incompatible USE all the way to the end. It's a
> major pain in the butt.

As Alan explained the setting of ABI_X86 globally will force *all* of your 
packages to build 32bit binaries.  IMHO, an awful waste of electrons.

Why don't you just set ABI_X86 only for the packages that request it, in 
package.use?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] Re: Solved: ABI_X86=

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Mon, 29 Feb 2016 16:59:27 +0000 (UTC), James wrote:

> Is there a provision (mechanism) to have this autoset, if a package
> dependency call for it? The system was fine for a quite a while until I
> forced it to only install 64 bit libs. What's the proper (auto) fix, as
> I do not remember having to have all of these 32 bit libs before, only
> a few?

The --autounmask option for emerge, which is on be default, partially
automates this. --autounmask-write takes it a small step further, but you
still have to run etc-update to apply the changes.

man emerge explains more.


-- 
Neil Bothwick

Sometimes too much to drink is not enough.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: Solved: ABI_X86=

[Rich Freeman]

On Mon, Feb 29, 2016 at 5:20 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Mon, 29 Feb 2016 16:59:27 +0000 (UTC), James wrote:
>
>> Is there a provision (mechanism) to have this autoset, if a package
>> dependency call for it? The system was fine for a quite a while until I
>> forced it to only install 64 bit libs. What's the proper (auto) fix, as
>> I do not remember having to have all of these 32 bit libs before, only
>> a few?
>
> The --autounmask option for emerge, which is on be default, partially
> automates this. --autounmask-write takes it a small step further, but you
> still have to run etc-update to apply the changes.
>

This is about the only solution today.  There has been talk of
implementing "lazy use flags" that would let portage implicitly change
USE settings when the user hasn't explicitly told it not to.  (That
is, interpret -flag as the user intends to leave it off, and flag as
the user intends to set it, and if it isn't mentioned one way or the
other let portage just follow profile/package defaults and add
per-package flags when needed to satisfy dependencies.)  This was
motivated in part by the package.use explosion caused by 32-bit libs.

However, none of this exists today.

-- 
Rich

[gentoo-user] Re: Solved: ABI_X86=

[James]

Mick <michaelkintzios <at> gmail.com> writes:

> As Alan explained the setting of ABI_X86 globally will force *all* of your 
> packages to build 32bit binaries.  IMHO, an awful waste of electrons.

Thx Alan. agreed.

> Why don't you just set ABI_X86 only for the packages that request it, in 
> package.use?

I put those 32 bit entries into /etc/portage/package.use/abi.use to keep 
them separate. Yes I agree with what you guys are saying.

thx,
James

[gentoo-user] Re: Solved: ABI_X86=

[James]

Rich Freeman <rich0 <at> gentoo.org> writes:


> > The --autounmask option for emerge, which is on be default, partially
> > automates this. --autounmask-write takes it a small step further, but you
> > still have to run etc-update to apply the changes.

Yes, I have had '--autounmask-write y' as part of my EMERGE_DEFAULT_OPTS= in
make.conf for a few years now. it does help.

after it does it's thing, I parse out the permanent flag setting  to
/etc/portage/package.use/package.use. As of today, I now manually parse out
the abi_x86_32 flags into /etc/portage/package.use/abi.use, knowing that the
system does autoset the 64bit as default for the default amd64 profile.



> This is about the only solution today.  There has been talk of
> implementing "lazy use flags" that would let portage implicitly change
> USE settings when the user hasn't explicitly told it not to.  (That
> is, interpret -flag as the user intends to leave it off, and flag as
> the user intends to set it, and if it isn't mentioned one way or the
> other let portage just follow profile/package defaults and add
> per-package flags when needed to satisfy dependencies.)  This was
> motivated in part by the package.use explosion caused by 32-bit libs.

I must confess to reading that thread, only too quickly. If I recall some
folks had an informal mechanism to already implement their idea of 'lazy
flags'? I'll have to reread that thread to parse out a few ideas on how to
move forward...

> However, none of this exists today.

As stated above, using /etc/portage/package.use/abi.use as a file to
exclusively put all of those settings, I hope a hack of an idea emerges to
solve this situation. Maybe an extended attribute that allows one to take
specific flages (like abi_x86_32) and put those into an isolated file under
/etc/portage/ might be an easy extension until the one of the devs moves
forward on this opportunity to implement 'lazy flags'?


Thx for the info and suggestions.

James