[Exherbo-dev] Multiarch discussion

Bo Ørsted Andresen zlin at exherbo.org
Sat Feb 8 22:41:39 UTC 2014

On Sat, 8 Feb 2014 13:54:09 -0800
Saleem Abdulrasool <compnerd at compnerd.org> wrote:
> - 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).
> I agree that the assumption that ${arch}- is the tool prefix is
> incorrect. That is something that exheres should be able to query
> from paludis. However, that is something that we can do once we are
> certain that we have the desired infrastructure.
> The CFLAGS handling is an ugly wart in the system that is the
> artifact of how the prototype was built.  I based the build
> infrastructure heavily based upon the excellent work that zlin and
> company did when I initially brought up multibuild (multilib) on
> exherbo.  cross does not follow the same build mentality, but rather
> relies on paludis targets for targeting each host.  This is obviously
> something that needs to be revisited.  One thought that comes to mind
> is to use a target hierarchy for environments, and introduce the
> concept of a default target.  You could imagine something like:
> /etc/paludis/armv7-unknown-linux-gnueabihf/bashrc
> /etc/paludis/i686-pc-linux-gnu/bashrc
> /etc/paludis/x86_64-pc-linux-gnu/bashrc
> /etc/paludis/default -> /etc/paludis/i686-pc-linux-gnu

bashrc configuration aside, I think we need to support separate
profiles per destination. And with that in place we should be able to
abandon the CROSS_* handling that's currently hard-coded into
ebuild.bash on the wip/cross-compiling paludis branch.

> > 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.
> I have no intentions of merging this into master until cross is deemed
> ready to merge into master.  The work that is on the WIP branch is
> specific to cross.  The parts work that I did to enable some of this
> is now merged to master.  Unless there is some other functionality
> that is enabled by the current work on the WIP branch, I would rather
> leave it there.  This is primarily driven by the motivation to not
> unnecessarily cause churn on master until we are sure that we are
> happy with the infrastructure for cross.

We really do need to support more than one cross destination in the
same paludis environment...

> > 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?
> There was no concrete proposal that I put forth for this, only vague
> mutterings that I think are some things that we should consider to
> improve the infrastructure for cross.  If there is a particular point
> that is unclear to you, I can try to expound on that.

I think we probably need one or more additional DEPENDENCY labels.

First we need to analyse how many different relations exist between a
cross compiled package and its dependencies on the cross platform and
the host platform.

Then hopefully we can map each of those kinds of relations to one or
more labels.

Bo Ørsted Andresen

More information about the Exherbo-dev mailing list