Mailing List Archive

why both /usr/lib and /usr/lib64 on a 64bit system?
Hello,
I use the global flags USE="elogind alsa -multilib -abi_x86_32" and I
thought this would prevent 32bit libraries to be installed.

For example I have (from glibc) both:

/usr/lib/libutil.so
/usr/lib64/libutil.so

this causes problems with some packages outside portage that I would
like to install. The install fails (or is incomplete) because it is
trying to link a 32bit incompatible library, e.g.:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
skipping incompatible /usr/lib/libutil.so when searching for -lutil

Is there a way to have only /usr/lib64 in gentoo or is this not
possible? I do use

export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH

in my shell startup file.

Thanks for inputs.
--
Valmor
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
I think there will always be some things that want /usr/lib. That said,
I'm guessing you started with a no-multilib tarball? Frankly, I find
there's still too many programs that want 32bit libraries to go full
no-multilib. Maybe in a few more years as the last of the 32bit only
machines die off and are replaced with 64 bit machines.

On 2/13/2021 12:33 PM, Valmor F. de Almeida wrote:
>
> Hello,
> I use the global flags USE="elogind alsa -multilib -abi_x86_32" and I
> thought this would prevent 32bit libraries to be installed.
>
> For example I have (from glibc) both:
>
> /usr/lib/libutil.so
> /usr/lib64/libutil.so
>
> this causes problems with some packages outside portage that I would
> like to install. The install fails (or is incomplete) because it is
> trying to link a 32bit incompatible library, e.g.:
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> skipping incompatible /usr/lib/libutil.so when searching for -lutil
>
> Is there a way to have only /usr/lib64 in gentoo or is this not
> possible? I do use
>
> export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH
>
> in my shell startup file.
>
> Thanks for inputs.
> --
> Valmor
>
--
Dan Egli
On my test server
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On 2/13/21 9:38 PM, Dan Egli wrote:
> Frankly, I find there's still too many programs that want 32bit
> libraries to go full no-multilib.

Are the programs that you're referring to things that are installed
through something other than emerge?

I'd naively assume that anything emerged on a system with no-multilib
would be 64-bit.

What am I missing?



--
Grant. . . .
unix || die
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On 2/14/21 12:22 AM, Grant Taylor wrote:
> On 2/13/21 9:38 PM, Dan Egli wrote:
>> Frankly, I find there's still too many programs that want 32bit
>> libraries to go full no-multilib.
>
> Are the programs that you're referring to things that are installed
> through something other than emerge?
>
> I'd naively assume that anything emerged on a system with no-multilib
> would be 64-bit.
>
> What am I missing?
As I remember, /lib and /usr/lib hold not only 32 bit libraries, but
non-arch or arch-irrelevant (I know there's a better term) files. Maybe
they are not explicitly libraries, but things like perl, python, or
shell scripts.  I don't think you can completely get rid of it.  I make
no claim as to whether you could get rid of all 32 bit libraries.
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
Am Sun, Feb 14, 2021 at 12:51:30PM -0500 schrieb Jack:

> As I remember, /lib and /usr/lib hold not only 32 bit libraries, but
> non-arch or arch-irrelevant (I know there's a better term) files.

arch-agnostic? ;-)

--
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

A neutron walks into a bar:
“How much for a beer?” – “For you, no charge.”
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On 2/14/21 4:48 PM, Frank Steinmetzger wrote:
> Am Sun, Feb 14, 2021 at 12:51:30PM -0500 schrieb Jack:
>
>> As I remember, /lib and /usr/lib hold not only 32 bit libraries, but
>> non-arch or arch-irrelevant (I know there's a better term) files.
> arch-agnostic? ;-)

Thanks.  I think that's it.


Totally OT - if there is an arch-agnostic, is there an arch-atheistic? 
Or would that be an abacus or paper and pencil?
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Sun, 14 Feb 2021 17:12:11 -0500, Jack wrote:

> Totally OT - if there is an arch-agnostic, is there an arch-atheistic? 
> Or would that be an abacus or paper and pencil?

Or someone who only has rectangular doorways ;-)

SCNR

--
Neil Bothwick

"Two things are infinite: the universe and human stupidity;
and I'm not sure about the the universe."
(Albert Einstein)
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Sat, Feb 13, 2021 at 2:33 PM Valmor F. de Almeida
<val.gentoo@gmail.com> wrote:
>
>
> Hello,
> I use the global flags USE="elogind alsa -multilib -abi_x86_32" and I
> thought this would prevent 32bit libraries to be installed.
>
> For example I have (from glibc) both:
>
> /usr/lib/libutil.so
> /usr/lib64/libutil.so
>

In case you haven't already figured it out, glibc ignores the setting
of abi_x86_32. It is controlled by your profile selection. Part of
that might be legacy, but if you build glibc without lib32 support it
is basically impossible to add it in later without bootstrapping it.

If you don't want multilib then you can use a no-multilib profile.

--
Rich
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On 2/14/21 10:51 AM, Jack wrote:
> I don't think you can completely get rid of it.

My (long term) desire is to do away with /lib32 and /lib64, ultimately
only using /lib. Likewise for the other library directories in /usr or
wherever they are. I don't see a need for the specific bit variants in
the future.



--
Grant. . . .
unix || die
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Sun, Feb 14, 2021 at 06:09:58PM -0700, Grant Taylor wrote
> On 2/14/21 10:51 AM, Jack wrote:
> > I don't think you can completely get rid of it.
>
> My (long term) desire is to do away with /lib32 and /lib64, ultimately
> only using /lib. Likewise for the other library directories in /usr or
> wherever they are. I don't see a need for the specific bit variants in
> the future.

How long before we see /lib and /lib64 *AND* /lib128 ?

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Sunday, 14 February 2021 21:48:36 GMT Frank Steinmetzger wrote:
> Am Sun, Feb 14, 2021 at 12:51:30PM -0500 schrieb Jack:
> > As I remember, /lib and /usr/lib hold not only 32 bit libraries, but
> > non-arch or arch-irrelevant (I know there's a better term) files.
>
> arch-agnostic? ;-)

No, it should be arch-neutral. Agnosticism is about religion and has nothing
to do with it.

--
Regards,
Peter.
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
Peter,

On Monday, 2021-02-15 12:15:43 +0000, you wrote:

> ...
> No, it should be arch-neutral. Agnosticism is about religion and has nothing
> to do with it.

First sentence: arch-independent?
Second sentence: yep :-)

Sincerely,
Rainer
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Mon, Feb 15, 2021 at 3:17 AM Walter Dnes <waltdnes@waltdnes.org> wrote:
>
> On Sun, Feb 14, 2021 at 06:09:58PM -0700, Grant Taylor wrote
> > On 2/14/21 10:51 AM, Jack wrote:
> > > I don't think you can completely get rid of it.
> >
> > My (long term) desire is to do away with /lib32 and /lib64, ultimately
> > only using /lib. Likewise for the other library directories in /usr or
> > wherever they are. I don't see a need for the specific bit variants in
> > the future.
>
> How long before we see /lib and /lib64 *AND* /lib128 ?

Well, anything is possible, but it seems unlikely. If it happens soon
then chances are that multilib will still be a thing and so less stuff
will break than when amd64 was introduced. If it happens in a century
when we're all running no-multilib then we'll be reinventing the
wheel.

The main things that drove amd64 though were:
* increasing the number of registers available
* allowing direct access to >4GB of RAM (or a fraction of this
depending on the OS design)

I suspect the first is less of a concern these days - compilers
generally only need so many registers and when instructions are added
that need more register space they tend to come with registers to
accommodate them. The second will be a concern when exabyte-scale
data structures are common to work with. Note that current processors
generally can't handle this much address space, but the amd64
instruction set itself can (I think), so the CPUs can continue to
scale up. RAM capacity doesn't really seem to be increasing in recent
years - I'm not sure if that is more market-driven or a technological
limitation. RAM speed has improved somewhat, especially in niches
like GPUs. Computers with 1GB of RAM were a thing in Y2K and today it
is pretty uncommon for a standard desktop to have more than 8GB, and
if you want to even cram more than about 128GB into a motherboard you
start needing more enterprise-grade hardware. That isn't a very large
increase in 20 years - doubling every 3 years (in terms of max
capacity). We're using 37 bits today (on desktops), so at 3 years per
bit that is another 80 years until we exhaust 64 bits, assuming that
we continue to grow exponentially at the same rate. Though you do
have to think about what use cases actually need that kind of working
set. At 64-bit depth 300dpi 3D graphics would require 200MB/in^3, If
you had a house-sized VR space (20k ft^3) rendered at that detail
you'd need 7TB of RAM to store a frame of video, which is still only
50 bits. Maybe if you want a holodeck that 1000 people can play
around in at once you'd run into the 64-bit limit (of course you'd
have a ton of IO issues to fix long before then).

So, that makes me wonder what the practical requirements are in order
to implement The Matrix. :) Of course, if you're sticking people in
it maybe you can borrow some of their own memory capacity and
processing abilities to drive it. Kind of makes you wonder why you'd
even need the human brains in the first place if you're able to deal
with that kind of data in a simulation...

--
Rich
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On February 15, 2021 4:15:43 AM PST, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>On Sunday, 14 February 2021 21:48:36 GMT Frank Steinmetzger wrote:
>> Am Sun, Feb 14, 2021 at 12:51:30PM -0500 schrieb Jack:
>> > As I remember, /lib and /usr/lib hold not only 32 bit libraries,
>but
>> > non-arch or arch-irrelevant (I know there's a better term) files.
>>
>> arch-agnostic? ;-)
>
>No, it should be arch-neutral. Agnosticism is about religion and has
>nothing
>to do with it.

Technically "canonical" also only applies to religious texts. That doesn't keep us from using it descriptively in other areas.

Bigger problem is that "arch agnostic" would mean only that the program is incapable of knowing what the arch was. Not that it can work with any arch or that the arch is irrelevant. So "independent" or "neutral" is a better choice in this context.

LMP
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On 2/14/21 5:54 PM, Rich Freeman wrote:
> On Sat, Feb 13, 2021 at 2:33 PM Valmor F. de Almeida
> <val.gentoo@gmail.com> wrote:
>>
>>
>> Hello,
>> I use the global flags USE="elogind alsa -multilib -abi_x86_32" and I
>> thought this would prevent 32bit libraries to be installed.
>>
>> For example I have (from glibc) both:
>>
>> /usr/lib/libutil.so
>> /usr/lib64/libutil.so
>>
>
> In case you haven't already figured it out, glibc ignores the setting
> of abi_x86_32. It is controlled by your profile selection. Part of
> that might be legacy, but if you build glibc without lib32 support it
> is basically impossible to add it in later without bootstrapping it.
>
> If you don't want multilib then you can use a no-multilib profile.
>

I ended up using:

USE="elogind alsa -multilib -multiarch -abi_x86_32"

but some libraries from glibc remain 32bit. My main goal was to remove
32bit libraries from libX11. This did happen since nvidia-drivers was
installing the 32bit versions of libX11 if -multilib -abi_x86_32 were
not used; maybe I should have used this in package.use/nvidia-drivers
instead globally.

Thanks for all the responses.
--
Valmor
Re: why both /usr/lib and /usr/lib64 on a 64bit system? [ In reply to ]
On Tue, Feb 16, 2021 at 10:57 AM Valmor F. de Almeida
<val.gentoo@gmail.com> wrote:
>
> USE="elogind alsa -multilib -multiarch -abi_x86_32"
>
> maybe I should have used this in package.use/nvidia-drivers
> instead globally.

Setting abi_x86_32 globally isn't really a big problem.

I wouldn't go messing with multilib/multiarch unless you really know
what you're doing. I suspect at some point having these modified
globally is going to cause serious breakage.

--
Rich