On Tue, Sep 01, 2020 at 09:16:48AM +0200, Ulrich Mueller wrote:
> >>>>> On Tue, 01 Sep 2020, Yuri Khan wrote:
> 
> >> > AFAIU `/usr/libexec` would be for binaries in general, infact we store
> >> > there the pdumper img.  Okay for `/usr/lib`.
> >> 
> >> It should be ${libdir} I think? That is, "lib64" on 64-bit systems.
> 
> > I am on a 64-bit system and my /usr/lib64 is empty except for a single
> > ld-linux-x86-64.so.2 symlink. On the other hand, /usr/lib32 contains a
> > number of shared objects belonging to the libc6-i386 package. This
> > tells me maybe native bitness belongs in /usr/lib.
> 
> I should have been more precise. It is in fact distro specific, so there
> may be 64-bit systems where the native libs are installed in /usr/lib
> (and 32-bit libs would go to /usr/lib32), while others install the
> native libs in /usr/lib64.

Yes. Those are the ad-hoc "solutions" you find "in the wild". And
then there is Debian multiarch [1], which is the "right" solution
(roughly: /lib and /usr/lib contain the "native" stuff, for
backward-compatibility; "foreign" stuff lives in
{/lib,/usr/lib}/<arch-triplet>, e.g. /usr/lib/i386-linux-gnu. [2]

After all, there's no reason not to want to have Arm binaries in
an x86_64 machine (there's qemu, after all).

> So the right thing to do is to use configure's ${libdir}.

Exactly. Looking at one's distro and generalizing is going to bite
someone. And then they'll be angry at us :)

So use the configury, and fix that should it be broken.

Cheers

[1] https://wiki.debian.org/Multiarch/TheCaseForMultiarch
[2] I said roughly. It's not (alas!) the well-known GNU triplet,
   but something similar, for Reasons [3]
[3] https://wiki.debian.org/Multiarch/Tuples

 - t