[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pure-mulitarch Cross Toolchains

On Wed, Jan 16, 2013 at 04:30:06PM +0000, Wookey wrote:

> It was done in Thibg's GSOC project for 4.7.2-4. Yes it needs more
> work to properly integrate, test, and make bootstrappable, but we have a
> working implementation (modulo keeping up with your amazing rate of
> new uploads :-). (For which kudos, even if it does make it hard to
> keep up!)

This still needs more work, obviously, but I would like to point out that
keeping up will be easier, as my patches (all of them) have made their
way to gcc-4.7/experimental.


> I am not convinced of the benefit in also maintaining toolchains with
> these libraries installed twice in different locations, now that we
> have multiarch to make this unnecessary.

In an ideal world, indeed.
But there are some issues inherent to multiarch (ld.so path...) preventing
co-instability on some arches. So, the other approach is still necessary.


> The main disadvantage of making use of the multiarch libraries is the
> need to keep libgcc, libstdc++ etc in version lockstep across
> architectures. But this applies to multiarch in general for all
> libraries, and is something we manage in Debian as part of being a
> distro. It is something to carefully consider. Is the reduced
> independence of the cross-toolchain library versions a fatal flaw?

It is needed anyway when one wants to take advantage of multiarch to
install additional build-dependencies (for instance, say you want
to cross-build a game depending on SDL. You would want to install
libsdl1.2-dev:$host, which depends on libgcc1:$host, which has to be
the exact same version as libgcc1:native).

> The main advantage is that the code you build against is actually the
> code the toolchain was built against, not some other code that happens
> to be installed in the expected location. Also build-dependencies work
> automatically without having to have 'equivs' packages for libgcc1,
> libstc++6-dev etc until the real native ones are built. And having one
> copy of libgcc1:<targetarch>, libstdc++:<targetarch> on the system
> instead of two seems like good practice to me. 

Exactly. To use my previous example, you can either use dpkg-cross
or something similar on libsdl1.2-dev:$host, without taking advantage
of multiarch at all, or use libsdl1.2-dev:$host directly (which seems
to be the most sensible approach to me). In the latter case, it brings
libgcc1:$host too. Having some libgcc1-$triplet-cross seems unnecessary.


> Using multiarch libraries also greatly simplifies the gcc packaging
> (if we are able to drop multilib equivalents as a result). Again we
> disagree on this point.

While I don't really like multilib, it's unrealistic to assume we can
drop it just like that (lots of build systems rely on -m32 and the likes).
It might be possible to implement it *using* multiarch, though, and
I plan to take a look at it soonish.

[snip, your mail is really getting long ;)]

> I am happy to be persuaded that this is madness with real examples of
> why we can't/shouldn't do things this way (and I can see that
> deprecating multilib support where it is well-established and code is
> co-runnable (x86_64 and i386) is not going to happen), but I've been
> doing it for years for arm and it seems sensible to me. 

That is why the two approachs have to be available for the time being.

Attachment: signature.asc
Description: Digital signature

Reply to: