Hi compnerd,
On Sat, 08 Feb 2014 13:54:09 -0800, Saleem Abdulrasool <[email protected]>
wrote:
> I would be strongly against changing this aspect of the implementation that
> I proposed and prototyped.
Thanks for your thorough response. I've been regrettably convinced that
this is a necessary change to make. It's a shame there are no standard
paths that don't clash.
> Secondly, you didnt consider the subtleties of my proposal. Multilib is a
> horrendous hack that GCC has implemented and this change intends to repair
> the damage from that.
>
> You must first canonicalise the paths: everything goes to /lib, trim
> dirname. Second, canonicalise the basename arc: drop the DSO version
> information.
>
> So what you are left with at the end of this exercise:
>
> AArch64: ld-linux-aarch64.so
> IA-64: ld-linux-ia64.so
> ARM HF: ld-linux-armhf.so
> ARM SF: ld-linux.so
> x32: ld-linux-x32.so
> x86-64: ld-linux-x86-64.so
> Alpha64: ld-linux.so
> x86: ld-linux.so
> SPARC: ld-linux.so
> SPARC64: ld-linux.so
> SH: ld-linux.so
>
> Now, you didnt consider MIPS. Lets look at that: {LE, BE}, {32, 64},
> {OABI, NABI} (for the sake of simplicity, Im ignoring the fact that there
> is actually o32, n32, n64). That is 2 * 2 * 2: 8 combinations.
>
> Now, you didnt really consider ARM 32. You listed HF, SF. Thats
> uninteresting. Lets really look at ARM32: {LE, BE}, {EABI, GNUEABI},
> {Soft, Soft Float, Hard Float} that is 2 * 2 * 3: 12 combinations.
>
> You also glossed over PPC32 and PPC64.
I'm not sure why these didn't come up when I greped through the GCC
sources. But you're right, I hadn't considered them.
However, this does bring up another point: how do we deal with the
multitude of possible ABIs a user might want to target. Obviously it
doesn't make sense to add each ABI to each package supporting the
"targets:" suboption.
Maybe the set of targets could be something specified by the user (or at
list chosen from some global list of acceptable targets), and then
packages like gcc can do comparisons on various parts of the target
triple (i.e. matching against arm-*-*-* to determine that it is an ARM
target). Packages could fail in pkg_pretend if they don't support the
given target triple. Also, packages would have to declare somehow that
they require a set of target architectures to build. This also works
better for a package like pkg-config, which really doesn't care what
strings you give it as the set of target architectures.
> At the very least the ABI is something which can be switched. MIPS (with
> the exception of the R8000) and PPC can also switch endianness! The
> current cross implementation makes handling this a breeze: just switch a
> symlink and be on your way.
I wasn't aware of this.
> 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.
Sounds good to me.
> 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
>
> (I use this as an example since this is pretty close to my setup).
This also is fine to me.
> > - 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.
> >
>
> 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.
What I meant was about how we currently can only target one architecture
with -m cross-compile. I agree that the current work on the WIP should
remain there until it is finalized.
> 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.
Now that I look at it a bit more, it makes a little more sense to me. I
think my confusion arose from usage of "build", "target", and "host",
without emphasizing in some way that they refer to architectures.
I do like zlin's proposal of adding another label, which could mean
"this package needs to be installed for the architecture this install is
targeting", or something along those lines.
--
Michael Forney <[email protected]>
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
