[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