Re: [Pkg-rust-maintainers] Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: Bug#881845: rustc: FTBFS on mips*: test failures

YunQiang Su <[email protected]>
Newsgroups gmane.linux.debian.ports.mips
Message-ID <CAKcpw6VdcOu2KdOcUNnviAxgqb43K-+RWkY9OEjva31F2HSVeQ@mail.gmail.com>
add Dragan Mladjenovic, who is maintaining rust for mips.

@Dragan can you help to debug rustc on mips64el, we have some test failures.

I noticed that we allow more test failures on some arch.
Can we also do it for mips64el for temporary?
Aron Xu <[email protected]> 于2018年10月3日周三 下午8:40写道:
>
> On Wed, Oct 3, 2018 at 5:54 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
> >
> > On 10/3/18 10:35 AM, Emilio Pozuelo Monfort wrote:
> > >> Can you backport the llvm fix to llvm 7?
> > >
> > > Actually given 7 is not in testing and rust is not using it atm, what would be
> > > good is to have this backported to llvm 6 asap, so that we can (hopefully) get
> > > rust bootstrapped in mips*, which is blocking quite some stuff.
> >
> > Even if you fix this particular bug, you are still running into the unfortunate
> > situation on the 32-bit MIPS architectures that there is not enough virtual
> > address space per process for Rust to work so you will always end up in
> > out-of-memory situations when building rustc natively on 32-bit MIPS.
> >
> > I have done extensive testing and tried lots of different approaches to
> > reduce the memory footprint of the Rust compiler, but so far I have
> > never succeeded in building rustc natively on 32-bit MIPS.
> >
>
> I haven't tried this yet. Wonders if it's doable to build 32bit rustc
> natively without debugging symbols (where Debian builds full debug
> symbols which consumes a lot of the address space), if that's doable
> we can consider adding something like -gsplit-dwarf to rustc to relax
> the situation.
>
> Regards,
> Aron



-- 
YunQiang Su
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.