Base Directory Specification and plugins

[Simon McVittie]

On Sun, 21 Nov 2010 at 02:28:20 -0500, Ryan Lortie wrote:
> On Sat, 2010-11-20 at 20:15 -0600, Gary Kramlich wrote:
> > That leaves the data directory.  However, the data directory on a unix
> > machine ends up being ~/.local/share and putting a native plugin under a
> > share directory seems to be completely wrong to me.
> 
> Your concern here is misplaced.  You can logically claim that it is
> either completely incorrect to place native binaries in the user home
> directory or that it is safe to blindly do so without consideration of
> the "share" vs. "lib" issue.  Which one you choose depends on your
> assumption about the different sorts of computers that the user's home
> directory might end up being used on.

There's been discussion of this issue on this list before. One way to support
sharing a home directory between ABIs (imagine an NFS $HOME that can be mounted
from an x86, x86-64 or arm machine) without colliding is to put the
libraries in an ABI-specific directory, or give them ABI-specific
names, or something.

The most general and widely used naming scheme for ABIs in Free
Software seems to be the "GNU triplets" used by autoconf and gcc, which look
like CPU-OS or CPU-KERNEL-OS (e.g. x86_64-linux-gnu for Linux with GNU libc on
x86-64, arm-linux-uclibc for Linux with uclibc on ARM, i486-freebsd for
FreeBSD (both kernel and libc) on x86, or whatever).

One common practice for cross-compilation is to put the cross-compiler and
host libraries in /usr/CPU-[KERNEL-]OS, e.g. /usr/arm-linux-gnu/{bin,lib};
cross-compiler binaries are also typically called something like
arm-linux-gnu-gcc, where arm-linux-gnu is the host system (the system where
the binaries produced by this compiler are going to be used).

Current proposals for multiarch in LSB and Debian-derived distributions
http://lackof.org/taggart/hacking/multiarch/,
http://wiki.debian.org/multiarch, https://wiki.ubuntu.com/MultiarchSpec) use
GNU triplets to name subdirectories of /usr/lib, e.g. /usr/lib/arm-linux-gnu.

So, I'd suggest mirroring those and using ~/.lib/CPU-[KERNEL-]OS/myapp/*.so.

autoconf's config.guess/config.sub produce a related construct, CPU-MACHINE-OS
or CPU-MACHINE-KERNEL-OS, but the MACHINE part is mostly obsolete these days -
it comes out as 'unknown' or 'pc' in most environments - and doesn't seem to be
relevant to ABIs (cross-compilation didn't traditionally use it, and multiarch
doesn't use it either).

Regards,
    S