On Wed, Jan 16, 2013 at 04:30:06PM +0000, Wookey wrote: [snip] > 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. [snip] > 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. [snip] > 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. [snip] > 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