[Exherbo-dev] Multiarch discussion

Michael Forney mforney at mforney.org
Thu Feb 6 04:49:49 UTC 2014


Hi,

While multiarch is getting closer, I think there are still a couple of
things that need discussion.

- PT_INTERP path of multiarch executables

Currently, we patch gcc in order to use a special path for the PT_INTERP
field of the resulting executables. This has the benefit of ensuring
that none of the dynamic loaders clash (as they are in architecture
specific lib directories).

However, it also has the downside of breaking binary compatibility with
other distributions (executables built on an Exherbo multiarch system
will not run on any other non-Exherbo system). I'm strongly of the
opinion that PT_INTERP should be left as /lib/ld-whatever.so for the
following reasons:

    1. The ld.so names on the architectures most people care about do
       not conflict. From the gcc sources, I've come up with this list:

       aarch64             /lib/ld-linux-aarch64.so.1

       ia64                /lib/ld-linux-ia64.so.2

       arm-hardfloat       /lib/ld-linux-armhf.so.3

       arm-softfloat       /lib/ld-linux.so.3

       x32                 /libx32/ld-linux-x32.so.2

       x86_64              /lib64/ld-linux-x86-64.so.2

       alpha               /lib/ld-linux.so.2
       i386                /lib/ld-linux.so.2
       sparc               /lib/ld-linux.so.2
       sparc64             /lib64/ld-linux.so.2
       sh                  /lib/ld-linux.so.2

       If someone really does want to add alpha, sparc, or sh support to
       Exherbo, these cases could be worked around in a case-by-case
       basis; e.g. we could change PT_INTERP for sparc to
       /lib/ld-linux-sparc.so.2

    2. Retain binary compatibility with other systems.

    3. We no longer need to create a /lib symlink, or manage a bunch of
       symlinks of dynamic loaders across libdirs for different
       architectures, or whatever is planned.

    4. We don't have to patch gcc as much (only the
       native_system_header_dir change is required from the current
       multiarch patch).

In any case, even if we do decide to continue using a special path for
PT_INTERP, I think that it is a major enough change to warrant some more
discussion (before it is difficult to change).

- build/host/target flags/tools

Currently there is no way to determine the correct settings for tools
and flags for the build or target architectures. As a workaround,
several packages assume build and target tools have a prefix of
${arch}-. Additionally, we don't get the variable inheritance that
ebuild.bash provides for the host system (CFLAGS being prepended to
CPPFLAGS). As far as how cross-compiling is currently set up in paludis,
I'm not sure how to solve this issue, because tool_prefix is set in the
installed repository config (and the build/target system installed
repository is not involved in the installation to a host installed
repository).

Implementation details aside, I think a tool that acts like this would
be neat:

    $(exarch build)
    # returns x86_64-pc-linux-gnu

    $(exarch host)
    # returns i686-pc-linux-gnu

    $(exarch build CC)
    # returns ${x86_64_pc_linux_gnu_CC}

    $(exarch build CFLAGS)
    # returns ${x86_64_pc_linux_gnu_CFLAGS}

    $(exarch arm-exherbo-linux-gnueabi CPPFLAGS)
    # returns ${arm_unknown_linux_gnueabi_CPPFLAGS} prepended by
    # ${arm_unknown_linux_gnueabi_CFLAGS}. Intended to be used by
    # packages which support target suboptions like gcc.

- paludis changes

I know that the cross-compiling branch is still a WIP, but I wonder what
the plan is for this. It is quite inconvenient to have to manage a bunch
of configs/environments in order to cross-compile for multiple hosts.

Also, dependency resolution for multiarch packages doesn't take into
account the architecture of installed packages. This makes users have to
do most dependency resolution for cross-compiled packages by hand at the
moment.

I see a brief mention of some necessary dependency syntax changes in the
TODO section of the multiarch migration guide, but I don't quite
understand the proposal. Maybe someone can expand upon this?

-- 
Michael Forney <mforney at mforney.org>



More information about the Exherbo-dev mailing list