[Exherbo-dev] [RFC] Unprefixed executables.

Bo Ørsted Andresen zlin at exherbo.org
Mon Mar 21 12:38:07 UTC 2016

On Thu, Mar 17, 2016 at 08:29:51PM +0100, Wouter van Kesteren wrote:
> It's well known that people want unprefixed executables (gcc, ld,
> and friends) so that we for example don't break people their `./configure
> make` and avoid having to resort to weird BUILDCC arguments to build the
> linux kernel. However we don't want these to be usable from inside of
> exheres because we value correctness over easiness there.
> We talked on and off about this on irc for a while now and we believe we
> have found a general and extendable solution that makes everyone happy.
> We want to designate a special directory (for the sake of this document
> say $libexec/paludis/exheres-0/banned/ for now, to be
> discussed) which packages can install to to shadow the real executables.
> directory will then be prepended to the PATH by paludis, effectively
> the real executables. When executed these fake executables will complain
> loudly and die.
> This has several neat advantages, we don't have to release paludis all the
> time for minor additions. We also don't end up with a huge list we have to
> maintain in a single place. This means that its nice and decentralized so
> when cat/pkg::3rdparty installs an unprefixed tool or gcc:7 introduces a
> one they don't have to contribute a patch to ::paludis or ::arbor to
update the
> list. As a minor bonus it also means we don't have have 'which gcj' return
> success in paludis-context when gcj isn't even installed, because its only
> shadowed the moment its actually installed.

Sounds good to me.

> The files in the /banned/ directory could be either symlinks to
> banned_in_eapi_exheres-0 or tiny wrappers like '#!/bin/sh' 'exec
> banned_in_eapi_exheres-0', the latter of which is i think preferred
> it means we can freely relocate the implementation in the future.

If we exec banned_in_eapi_exheres-0, does banned_in_eapi_exheres-0 actually
have a clue what called it? Has anybody tested this in practise?

> There are a couple of things that would need further discussion from this
> point, the main ones being:
> 1. what directory are we picking?
> 2. what will the implementation of the tiny ban scripts be?
> 3. do we want some helper like dobanned and/or env like BANNEDDIR given
> by paludis and/or exlib?

dobanned doesn't sound useful given that the implementation will sometimes
installed and sometimes be provided by an alternative. dobanned would only
the former, I think. BANNEDDIR does sound useful.
The other thing that hasn't been covered particularly well here is how to
create the
actual unprefixed executables.

Originally I thought I'd just create an alternative for all of them, but
then I realised that
the things we lack unprefixed executables for consist of things from five
toolchain packages and a dozen alternatives or whatever.

But I was also overcomplicating this, because an unprefixed executable for
gcc on
native amd64 needs to go in /usr/x86_64-pc-linux-gnu/bin/ while a gcc for
x86 needs
to go in /usr/i686-pc-linux-gnu/bin/ etc. /usr/bin/gcc will then just point
at whichever
of these directories /usr/host points at without further complications.

This all results in the fairly straight-forward solution implemented for
binutils and
pkg-config in:


More to come for gcc et al.

So the crux of it is that the unprefixed executable gets installed by
whatever installed
the prefixed executable whenever host and target are the same.

Bo Ørsted Andresen

More information about the Exherbo-dev mailing list