On 2016-06-01 16:24, YunQiang Su wrote: > On Tue, May 31, 2016 at 11:29 PM, Aurelien Jarno <[email protected]> wrote: > > On 2016-05-23 11:09, YunQiang Su wrote: > >> On Mon, May 23, 2016 at 2:59 AM, Aurelien Jarno <[email protected]> > >> wrote: > >> > control: merge 824985 824996 > >> > thanks > >> > > >> > On 2016-05-22 14:37, YunQiang Su wrote: > >> >> Package: src:glibc > >> >> Version: 2.22-9 > >> >> > >> >> Hi, I am working add MIPS r6 support for base toolchains. > >> >> This is the patch for glibc (2.22 only) > >> >> > >> >> I am also working on 2.23 also, and will submit soon. > >> > > >> > We'll apply the patch to the sid branch and merge it into 2.23. > >> > > >> > I have one global comment about it though. Do we need to keep multilib > >> > with the 3 ABI? It makes MIPS toolchain painfully slow to build and > >> > nowadays the same can be achieved with multiarch (or even with the > >> > plain old chroots). > >> > > >> > The same way should we really add support for n32? We have more and more > >> > issues to solve on 32-bit machines due to the limited address space, so > >> > if the host supports 64-bit instructions, we should go to full 64 bits. > >> > > >> > >> In fact I won't build them on Debian official build machines. > >> The multilib and N32 will help me to build cross toolchains. > >> > >> As we talked in the last Debconf, we are planning for migrate to 64bit, > >> while I still wish the patches for 32/n32/multilib still in the code base, > >> so I can build cross toolchains or base system in private repo. > > > > The patch for adding so many architectures is big (mostly due to > > multilib) and we'll have to maintain consistency for all > > debian/sysdeps/mips*.mk when doing a change. I guess that's acceptable > > though if we accept some of them will get broken over time. > > My plan is to have a continuous cross toolchain for all of these > architectures. > So, I prefer we can keep them. > > As r6 shared the same method in gcc with r5-, if we remove the multilib > support, we will have to make r6 different process with r5- in gcc. > > I think I can keep them sync.
Ok. > > > > Now the real question is about multilib support for MIPS R6. Do we > > really want to keep using multilib for them? This makes MIPS the slowest > > architectures to build the toolchain, while nowadays one can build > > cross toolchains without pre-existing multilib support. > > I don't think build time will be a big problem. Do you mean that R6 machines will be a *lot* faster than the current build daemons? We regularly have complains about the toolchain build time on mips*, and it's one of the arguments regularly used to drop mips* architectures from the debian archive. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
