Conan: Adding binutils version as a setting

Created on 2 Jul 2019  路  3Comments  路  Source: conan-io/conan

To help us debug your issue please explain:

  • [x] I've read the CONTRIBUTING guide.
  • [x] I've specified the Conan version, operating system version and any tool that can be relevant.
  • [x] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

Hi @lasote, we have encountered a similar problem that is described here: https://github.com/conan-io/conan/issues/223.

Short story:
We've built a library with 2.29 binutils version(created a package from it), then we tried to link it in an executable using 2.23 binutils(which comes by default with centos 7). We received an error at link time, just like this one from the referenced issue:

/1825751e274ec825270a47a80ec47dbf8278fa20/lib/libjpeg.a(jcmarker.o): unrecognized relocation (0x2a) in section `.text'
/usr/bin/ld: final link failed: Bad value

Is there a reason for why isn't the binutils version in the settings? This way you will be able to avoid these types of errors.

Thanks :smile:

question

Most helpful comment

Hi @chreniuc

Yes, there is a reason, and it is to avoid the explosions of binaries. As usual it is a trade-off.

If a binutils version is added, then every different binutils version would require generating a different binary, which is almost impossible, specially for the wider open source community.

In reality, not every minor binutils version generates incompatible code. Actually this issue could be handled in terms of glibc version or even distro versions.

So the current approach is:

  • Do not explicitly model the glibc/binutils/distro in the default settings.yml
  • These defaults are good for a very big majority of the open source community, which are using reasonable modern distros, compatible with the ones that are used to generate the binaries in conan-center and other public repos like bincrafters
  • Users that want to achieve a better granularity of binaries can easily extend the binary model, adding the binutils, glibc, or the distro (I think adding the distro works very well for private use, very intuitive and robust), as explained in: https://docs.conan.io/en/latest/extending/custom_settings.html. The customs settins are easy to manage with conan config install

Thanks for your feedback, please tell me if the above clarifies the rationale of the current approach. Cheers!

All 3 comments

Hi @chreniuc

Yes, there is a reason, and it is to avoid the explosions of binaries. As usual it is a trade-off.

If a binutils version is added, then every different binutils version would require generating a different binary, which is almost impossible, specially for the wider open source community.

In reality, not every minor binutils version generates incompatible code. Actually this issue could be handled in terms of glibc version or even distro versions.

So the current approach is:

  • Do not explicitly model the glibc/binutils/distro in the default settings.yml
  • These defaults are good for a very big majority of the open source community, which are using reasonable modern distros, compatible with the ones that are used to generate the binaries in conan-center and other public repos like bincrafters
  • Users that want to achieve a better granularity of binaries can easily extend the binary model, adding the binutils, glibc, or the distro (I think adding the distro works very well for private use, very intuitive and robust), as explained in: https://docs.conan.io/en/latest/extending/custom_settings.html. The customs settins are easy to manage with conan config install

Thanks for your feedback, please tell me if the above clarifies the rationale of the current approach. Cheers!

@memsharded I forgot to say that you can close this issue(I only upvoted you comment).

Thanks for your time, I got everything I needed.

We only encountered this problem once, so we do not know if we will add it as a setting, like you said it will be an explosions of binaries. If we will encounter it frequently we might reconsider.

But again, thank you for your time :smiley:

Thanks very much @chreniuc for following up and closing the issue 馃槂

Was this page helpful?
0 / 5 - 0 ratings