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

Bug#824985: glibc 2.22: add MIPS r6 support



On 2016-06-01 16:24, YunQiang Su wrote:
> On Tue, May 31, 2016 at 11:29 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On 2016-05-23 11:09, YunQiang Su wrote:
> >> On Mon, May 23, 2016 at 2:59 AM, Aurelien Jarno <aurelien@aurel32.net> 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
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: