New recipe for GNU Binutils

[frol]

The GNU Binutils are a collection of binary tools.

The main ones are:

• ld - the GNU linker.
• as - the GNU assembler.

But they also include:

• addr2line - Converts addresses into filenames and line numbers.
• ar - A utility for creating, modifying and extracting from archives.
• c++filt - Filter to demangle encoded C++ symbols.
• gprof - Displays profiling information.
• nm - Lists symbols from object files.
• objcopy - Copies and translates object files.
• objdump - Displays information from object files.
• ranlib - Generates an index to the contents of an archive.
• readelf - Displays information from any ELF format object file.
• size - Lists the section sizes of an object or archive file.
• strings - Lists printable strings from files.
• strip - Discards symbols.

P.S. This is useful on the systems with outdated binutils package (e.g. CentOS 6 couldn't build Boost with GCC 5.3 for me using the old binutils package from their repo), or in chroot environments without other package managers but conda.

[conda-forge-admin]

Hi! This is the friendly conda-forge-admin automated user.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/binutils) and found it was in an excellent condition.

[jakirkham]

This is getting pretty low level. Need to think about this a bit.

Could you please explain what sort of issues you were running into with Boost? We built it here with Continuum's gcc and the standard binutils from CentOS 6.

[frol]

@jakirkham I was hit by the issue described here: http://stackoverflow.com/questions/22300736/assemble-error-for-avx2

And just as the topic-starter, the issue was gone once I upgrade binutils to 2.22+.

[msarahan]

IMHO, we should be moving away from compilers and binutils as conda packages. Those are the domain of a build image, such as the docker image under debate in conda-forge/conda-forge.github.io#29 - I'd welcome your thoughts on the topic.

The docker image that I created uses CentOS 5 with binutils 2.26 and GCC 5.2.

Out of curiosity, why build with GCC 5.3 over 5.2? What does it offer you? Is it worth having in a build image?

[jakirkham]

Just as FYI, devtoolset-4 would also have a new enough build of binutils (2.25).

[frol]

@msarahan Starting from 5.x branch, GCC uses second version number for bug-fix releases, so 5.3 just has fewer bugs than 5.2 (I haven't hit any myself with 5.2, but why don't just upgrade to be on the safe side?).

[ocefpaf]

@frol I agree with @msarahan here in the sense that we should steer away from using those packages. However, I am not against packing, providing them in conda-forge, and using them in local experiments.

We just need a big warning in the README saying: Use this at your own risk. We won't use them as built tools in conda-forge as well.

Let's leave this open a little longer to see if other agree with me.

[jakirkham]

I started writing on this and the comment got so long that it started to just feel like a policy issue. So, it has been cleaned up and placed in this issue ( conda-forge/conda-forge.github.io#81 ). Let's please discuss there before proceeding any further here.

[msarahan]

@ocefpaf I like that line: packages for low-level tools like compilers, assemblers, and linkers, are provided for experimentation, but they're also installed in the docker image. Whatever the docker image has is "official" - and recipes won't be accepted with requirements on low-level tools. Rather, if any new tool or updated tool is necessary, then then official image will require an update.

I'm sure either way could cause pain down the road. If things aren't totally standard, there's opportunity for things to stop working for strange reasons. If we require an update to the build image, that in turn may break older things (and also raises questions about when we should rebuild things in those situations).

[ocefpaf]

Right now we don't have any mechanisms, besides human review, to ensure that new packages, or existing feedstocks, won't use experimental build tools as dependencies. Should we make a list of those and add to the linter? Is that too much? @pelson what do you think?

[jakirkham]

I have marked this as "Needs Decision" (blatantly stealing that from NumPy 😉) for now. However, I feel the decision needs to occur on the issue ( conda-forge/conda-forge.github.io#81 ) first before we address this.

[msarahan]

I'd say go ahead and merge here. Everything related to our official build tools (and deviation from them) is a policy decision, and merely having this package shouldn't force the issue.

[ocefpaf]

I'd say go ahead and merge here. Everything related to our official build tools (and deviation from them) is a policy decision, and merely having this package shouldn't force the issue.

Agreed. I will take a stab at implementing something in the linter to warn about binutils use in the recipes.

[jakirkham]

Not sure I agree, but it looks like that ship has sailed.

[ocefpaf]

Not sure I agree, but it looks like that ship has sailed.

2-1 😉

Since I merged I assign myself to improve the linter 😝

[jakirkham]

I'm not clear on the purpose of adding these if we intend for people not to use them. Could you please clarifying?

[ocefpaf]

Local experiments or use in other projects. I do fetch recipes from conda to other projects BTW. The fact that we won't use them as build tools in conda-forge does not mean they won't be used.

[jakirkham]

Local experiments or use in other projects. I do fetch recipes from conda to other projects BTW. The fact that we won't use them as build tools in conda-forge does not mean they won't be used.

By this logic, are we now ok with building compilers? In practice, it may overrun the CI time limit, but I would like to understand what this means.

[ocefpaf]

By this logic, are we now ok with building compilers?

I would say yes.

In practice, it may overrun the CI time limit, but I would like to understand what this means.

We do have that limitation though 😉

[msarahan]

By this logic, are we now ok with building compilers?

I agree. Where I want to draw the line is that any package that ends up on the conda-forge channel should be built with an extremely well-defined toolset, and not any of these experimental packages.

Experimental packages, on the other hand, are extremely important for exploring and developing tools to feed into future iterations of the standard build tool set. I would encourage their development, and I would also encourage discussion about when it is an appropriate time to update or change the standard build tool set.

[jakirkham]

Experimental packages, on the other hand, are extremely important for exploring and developing tools to feed into future iterations of the standard build tool set.

That's an interesting point.

In any event, let's discuss this more in the issue. It would be good to come to some sort of consensus on our policy regarding packages of this nature so we are not having to deal with them on a case by case basis. Further I think it would be helpful to have some buy-in from the larger community before creating more things of this nature.