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

RE: binutils arm-none and arm-linux

> From: Wookey [mailto:wookey@wookware.org]
> Sent: Monday, December 01, 2014 5:06 PM
> None of binutils-arm-none-eabi, cross-binutils (the two wrappers), nor
> even binutils-source itself contain any patches. So so far as I can tell we
> are already building both cross- packages from a common base.

Current version of binutils-arm-none-eabi does not but the next version
(uploaded in experimental today by Agustin) does. As already said, it
mostly consists of support for the new Cortex-M7 processor but also
some bug fixes. We have pre-approval unblock request [1] for it but
we'll see if RT is ok with that.

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771194

> The linux one is used for all arches, not just arm, but I'm not
> sure to what degree it's upstream binutils or linaro-modified
> binutils. The control file says it's from:
> https://code.launchpad.net/~doko/binutils/pkg-2.25-debian
> My understanding is that it is GNU binutils with a selection of
> patches (now commits) for debian fixes or from Linaro and possibly
> other places, including your changes for the arm-none support. It says
> 'Snapshot, taken from the 2.25 branch' I'm not sure if that is GNU
> upstream branch or something else? Doko?

Ok, if it's only fixes it shouldn't be a problem.

> > In practice different patches are applied, like the patch to support
> recently
> > released Cortex-M7 processors.
> Well. I thought that too, but I can't actually see any evidence of
> that. It looks to me like they are all already been integrated.

Take a look at the version in experimental. It was only in git when I replied
your email, I forgot about this.

> Although binutils-source _does_ have patches in. I'm not sure where
> they are coming from. None of them are obviously arm-none related,
> but
> I've not looked in detail.


> Right. The arm-none binaries are constructed with a pile of configure
> options to turn stuff off and set up the right set of multilibs, so
> there presumably is a fair divergence from the linux defaults, but one
> would have to check what the default set is. The rules files are
> currently quite divergent so it would take a bit of work to merge.

Yeah, at least the --enable-interwork really needs to be specified when
building the arm-none-eabi cross binutils.

> > I'll take a look at this but I guess we are talking Jessie+1 (I forgot its
> > name), right?
> Definitely. ('Stretch'). No hurry here, I just noticed the duplication
> of source packages and wondered if it was necessary.

Ok, sounds like a nice plan. I noticed you are the maintainer of this
package. Would you accept Agustin and I as co-maintainer? As to
me I cannot upload things myself as this is work I do as part of my
job so if there is more people that can sponsor my changes that's
all for the better. :-)

Best regards,


Reply to: