5 ms·

GNU Binutils 2.32 Released

66 points by edelsohn 8y ago

tyingq 8y ago
It mentions support for the C-SKY processor. Here's the dev board for it: https://www.mickmake.com/post/csky-sbc-pi-in-the-sky-review https://www.mickmake.com/post/csky-sbc-pi-in-the-sky-review
- xvilka 8y ago
  C-SKY Orange PI board is quite nice and cheap. We added C-SKY support in radare2 too.
  - tyingq 8y ago
    I don't think Orange PI is related...those use Allwinner ARM CPUs. It's likely the sales listing just said something like "C-SKY Orange PI Raspberry PI" or something, even though it was the board above, which has its own weird architecture that isn't ARM. For some reason AliExpress listings do that often... "generic thing + some recognizable brand unrelated to it"
ComputerGuru 8y ago
This project could greatly benefit from a CI system testing multiple popular distros. Every other release fails to compile on FreeBSD. I tried building from 2.31 then HEAD then rolled back to 2.30 to get it to compile under FreeBSD 12 (for an embedded system where the default patched version in ports didn’t cut it). I have notes I took last product release with a different bug, same scenario. Unfortunately many GNU projects treat non-Linux platforms as third class citizens (GNU autotools still doesn’t always generate Makefiles compatible with bsdmake).
- ggm 8y ago
  I think the BSDL/GPL wars made people less motivated to reach out to BSD platforms for compatibility. A lot of BSD energy goes into making base system work with as little GPL as possible. Is there no non-GPL toolsuite for the embedded systems you're targetting? I could believe the answer is either, both of (a) no and (b) but I need to keep compatibility with GPL produced .so and related objects.
  - ComputerGuru 8y ago
    Our toolchain is actually GPL-free, but the app itself involves the use of a disassembler with support for formats (at least not previously) supported by llvm-objdump.
    - ggm 8y ago
      I feel some sympathy for what you're exposed to, but I also suspect you're in a corner, or near a corner-case. Having said that, I haven't had to try and explore cross compilation for a very long time and have no dependency on it. I could well believe as a user the competing states are not helpful. Overall I like BSD licenced code, and I like the approach to minimise dependency on GPL licenced code, but When you get down into things like binary blobs for WiFi units soldered onto mainboards, and Video drivers, things pretty quickly favour the volume of users behind GPL. I just remind myself that 2D non-accellerated graphics are probably what I need even if better 3D is what I want (the binary blobs thing really annoys me)
  - ajross 8y ago
    Yeah, really a corrolary is the clearer explanation: Binutils runs poorly on BSD because no one working on BSD wants to work on binutils because they hate the FSF and are focusing their energies on llvm/clang toolchains. Which is their right, of course. But it's a little salty to then turn around and demand that the GNU people then be responsible for supporting them anyway.
    - ComputerGuru 8y ago
      > Binutils runs poorly on BSD because no one working on BSD wants to work on binutils because they hate the FSF and are focusing their energies on llvm/clang toolchains. Salty much? Where are you getting this from? binutils is included in the FreeBSD ports, which is a maintained collection of patches and build files to make the latest version of xxx to install and run on FreeBSD. > But it's a little salty to then turn around and demand that the GNU people then be responsible for supporting them anyway. I don’t represent FreeBSD and the above was my opinion alone. And I am a core maintainer on several popular GPL projects despite picking the MIT and BSD licenses for my own projects. Please take your hate and FUD elsewhere.
- asveikau 8y ago
  That's ironic given all that autotools stuff came about to get everything working on every conceivable proprietary Unix, and probably probes for a lot of things nobody will likely face.
- emmelaich 8y ago
  The bsd community could set up such a ci/cd system themselves. Then the GNU folks could use it or ignore it but they wouldn't be ignorant of problems. In fact for many issues timely notice is almost all it takes to get things fixed.
  - viraptor 8y ago
    With the current level of traffic (tens of commits a day on master) it would be within pocket money budget as well.
  - ComputerGuru 8y ago
    I don’t know. As an open source developer I put the onus on myself to make sure my releases (at the very least, not every commit) at least compile and run on Linux, macOS, WSL, and FreeBSD even though I don’t use the first two.
    - icelancer 8y ago
      I mean... you just named two enormous platforms that you should test for but don't use. FreeBSD is hardly equal to either of those. It's a much much different situation.
- bobbyi_settv 8y ago
  But gnu make can be built for freebsd without already having other gnu stuff (or itself), right? If so, is it really unreasonable for another gnu project to expect you to get gmake first and use that in order to compile the project?
  - ComputerGuru 8y ago
    The problem with binutils wasn’t make/gmake-related. I have no problem with requiring gmake as a rule, I maintain this: https://github.com/neosmart/gmake-proxy https://github.com/neosmart/gmake-proxy But the whole point of autotools is to write a flavor-agnostic Makefile that gets compiled into a working Makefile. For it not to work defeats the point.
    - acqq 8y ago
      > For it not to work defeats the point. It's just the tool to make the compatible releases possible. The compatibility doesn't fall from the sky, somebody should actively work on it. And you can be that someone.
- rurban 8y ago
  There's now Cirrus CI to use for free with FreeBSD images. It's also much faster than Travis CI (with macOS which is almost FreeBSD, at least their libc) and Appveyor CI. The GNU compiler guys have setup a oldstyle build farm which I've never used, but with savannah et al there's no free CI.
- pm215 8y ago
  I think part of the problem here is that if the only thing running on $MINORITY_PLATFORM is your CI loop, then when it does find an issue it's going to be harder for the devs to fix, and it's never going to get the breadth of coverage that daily use during development will (both from bits the tests don't cover and because the CI system is testing a specific OS version with a fixed set of installed packages, and likely doesn't get updated to new OS versions very promptly.) If users of an OS care about a program then there's no substitute for being involved upstream (and not just putting workaround patches in a local 'ports' system). QEMU has this issue -- in theory we support Linux, OSX, Windows, OpenBSD, FreeBSD, NetBSD (and CI on all of those), but Linux support is much better than all the rest because all of the primary developers are using that, and contributions from users of the other platforms are much rarer. It's not a policy decision to treat the others as third-class.
- Sir_Cmpwn 8y ago
  sr.ht has a broad selection of build bases which is only getting broader, including FreeBSD and soon to have NetBSD and hopefully OpenBSD: https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md You don't need to be an Official Important Binutils Person to set up some CI and use it to make bug reports. You should try it out!
- acqq 8y ago
  > Every other release fails to compile on FreeBSD. But in later message you also state: > Our toolchain is actually GPL-free It's obviously the conflict of the goals, where you, the way I understand it, can't complain that the GPL-based tools "don't always (in every release) perfectly (i.e. without any adjustments) work" on the platforms whose goal is to avoid the GPL. You should be lucky that they indeed fix the issues when somebody submits the patches. But the other communities can't expect from the GPL contributors to do the very work for which the said non-GPL communities exist. Or, in the words of my favourite Microsoft (i.e. non-GPL) developer: https://blogs.msdn.microsoft.com/oldnewthing/20110118-00 https://blogs.msdn.microsoft.com/oldnewthing/20110118-00 "Don’t just stand around saying somebody should do something: Be someone"
htfy96 8y ago
I hope the split dwarf problem was fixed (haven't checked it out), which would make linking way more faster.
rurban 8y ago
MD5 signatures, lol. They do have GPG .sig files now, so do they should announce it how to use it, as most other GNU projects. It's in the newer announce templates.
- ambrop7 8y ago
  I just pull GNU releases from https://ftp.gnu.org/gnu/ https://ftp.gnu.org/gnu/. One doesn't find HTTPS links in the official pages for some reason, but it exists.
verytrivial 8y ago
> Objdump's --disassemble option can now take a parameter, specifying the starting symbol for disassembly. Finally!
papaman 8y ago
A few days ago I tried "Linux from Scratch" (http://www.linuxfromscratch.org/ http://www.linuxfromscratch.org/) and I was learning about Binutils and the linux Toolchain. It's awesome to learn how important those core tools are for GNU/Linux.

66 points by edelsohn 8y ago

It mentions support for the C-SKY processor. Here's the dev board for it: https://www.mickmake.com/post/csky-sbc-pi-in-the-sky-review https://www.mickmake.com/post/csky-sbc-pi-in-the-sky-review

xvilka 8y ago
C-SKY Orange PI board is quite nice and cheap. We added C-SKY support in radare2 too.
- tyingq 8y ago
  I don't think Orange PI is related...those use Allwinner ARM CPUs. It's likely the sales listing just said something like "C-SKY Orange PI Raspberry PI" or something, even though it was the board above, which has its own weird architecture that isn't ARM. For some reason AliExpress listings do that often... "generic thing + some recognizable brand unrelated to it"

ComputerGuru 8y ago

This project could greatly benefit from a CI system testing multiple popular distros. Every other release fails to compile on FreeBSD. I tried building from 2.31 then HEAD then rolled back to 2.30 to get it to compile under FreeBSD 12 (for an embedded system where the default patched version in ports didn’t cut it). I have notes I took last product release with a different bug, same scenario. Unfortunately many GNU projects treat non-Linux platforms as third class citizens (GNU autotools still doesn’t always generate Makefiles compatible with bsdmake).

ggm 8y ago
I think the BSDL/GPL wars made people less motivated to reach out to BSD platforms for compatibility. A lot of BSD energy goes into making base system work with as little GPL as possible. Is there no non-GPL toolsuite for the embedded systems you're targetting? I could believe the answer is either, both of (a) no and (b) but I need to keep compatibility with GPL produced .so and related objects.
- ComputerGuru 8y ago
  Our toolchain is actually GPL-free, but the app itself involves the use of a disassembler with support for formats (at least not previously) supported by llvm-objdump.
  - ggm 8y ago
    I feel some sympathy for what you're exposed to, but I also suspect you're in a corner, or near a corner-case. Having said that, I haven't had to try and explore cross compilation for a very long time and have no dependency on it. I could well believe as a user the competing states are not helpful. Overall I like BSD licenced code, and I like the approach to minimise dependency on GPL licenced code, but When you get down into things like binary blobs for WiFi units soldered onto mainboards, and Video drivers, things pretty quickly favour the volume of users behind GPL. I just remind myself that 2D non-accellerated graphics are probably what I need even if better 3D is what I want (the binary blobs thing really annoys me)
- ajross 8y ago
  Yeah, really a corrolary is the clearer explanation: Binutils runs poorly on BSD because no one working on BSD wants to work on binutils because they hate the FSF and are focusing their energies on llvm/clang toolchains. Which is their right, of course. But it's a little salty to then turn around and demand that the GNU people then be responsible for supporting them anyway.
  - ComputerGuru 8y ago
    > Binutils runs poorly on BSD because no one working on BSD wants to work on binutils because they hate the FSF and are focusing their energies on llvm/clang toolchains. Salty much? Where are you getting this from? binutils is included in the FreeBSD ports, which is a maintained collection of patches and build files to make the latest version of xxx to install and run on FreeBSD. > But it's a little salty to then turn around and demand that the GNU people then be responsible for supporting them anyway. I don’t represent FreeBSD and the above was my opinion alone. And I am a core maintainer on several popular GPL projects despite picking the MIT and BSD licenses for my own projects. Please take your hate and FUD elsewhere.
asveikau 8y ago
That's ironic given all that autotools stuff came about to get everything working on every conceivable proprietary Unix, and probably probes for a lot of things nobody will likely face.
emmelaich 8y ago
The bsd community could set up such a ci/cd system themselves. Then the GNU folks could use it or ignore it but they wouldn't be ignorant of problems. In fact for many issues timely notice is almost all it takes to get things fixed.
- viraptor 8y ago
  With the current level of traffic (tens of commits a day on master) it would be within pocket money budget as well.
- ComputerGuru 8y ago
  I don’t know. As an open source developer I put the onus on myself to make sure my releases (at the very least, not every commit) at least compile and run on Linux, macOS, WSL, and FreeBSD even though I don’t use the first two.
  - icelancer 8y ago
    I mean... you just named two enormous platforms that you should test for but don't use. FreeBSD is hardly equal to either of those. It's a much much different situation.
bobbyi_settv 8y ago
But gnu make can be built for freebsd without already having other gnu stuff (or itself), right? If so, is it really unreasonable for another gnu project to expect you to get gmake first and use that in order to compile the project?
- ComputerGuru 8y ago
  The problem with binutils wasn’t make/gmake-related. I have no problem with requiring gmake as a rule, I maintain this: https://github.com/neosmart/gmake-proxy https://github.com/neosmart/gmake-proxy But the whole point of autotools is to write a flavor-agnostic Makefile that gets compiled into a working Makefile. For it not to work defeats the point.
  - acqq 8y ago
    > For it not to work defeats the point. It's just the tool to make the compatible releases possible. The compatibility doesn't fall from the sky, somebody should actively work on it. And you can be that someone.
rurban 8y ago
There's now Cirrus CI to use for free with FreeBSD images. It's also much faster than Travis CI (with macOS which is almost FreeBSD, at least their libc) and Appveyor CI. The GNU compiler guys have setup a oldstyle build farm which I've never used, but with savannah et al there's no free CI.
pm215 8y ago
I think part of the problem here is that if the only thing running on $MINORITY_PLATFORM is your CI loop, then when it does find an issue it's going to be harder for the devs to fix, and it's never going to get the breadth of coverage that daily use during development will (both from bits the tests don't cover and because the CI system is testing a specific OS version with a fixed set of installed packages, and likely doesn't get updated to new OS versions very promptly.) If users of an OS care about a program then there's no substitute for being involved upstream (and not just putting workaround patches in a local 'ports' system). QEMU has this issue -- in theory we support Linux, OSX, Windows, OpenBSD, FreeBSD, NetBSD (and CI on all of those), but Linux support is much better than all the rest because all of the primary developers are using that, and contributions from users of the other platforms are much rarer. It's not a policy decision to treat the others as third-class.
Sir_Cmpwn 8y ago
sr.ht has a broad selection of build bases which is only getting broader, including FreeBSD and soon to have NetBSD and hopefully OpenBSD: https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md You don't need to be an Official Important Binutils Person to set up some CI and use it to make bug reports. You should try it out!
acqq 8y ago
> Every other release fails to compile on FreeBSD. But in later message you also state: > Our toolchain is actually GPL-free It's obviously the conflict of the goals, where you, the way I understand it, can't complain that the GPL-based tools "don't always (in every release) perfectly (i.e. without any adjustments) work" on the platforms whose goal is to avoid the GPL. You should be lucky that they indeed fix the issues when somebody submits the patches. But the other communities can't expect from the GPL contributors to do the very work for which the said non-GPL communities exist. Or, in the words of my favourite Microsoft (i.e. non-GPL) developer: https://blogs.msdn.microsoft.com/oldnewthing/20110118-00 https://blogs.msdn.microsoft.com/oldnewthing/20110118-00 "Don’t just stand around saying somebody should do something: Be someone"

htfy96 8y ago

I hope the split dwarf problem was fixed (haven't checked it out), which would make linking way more faster.

rurban 8y ago

MD5 signatures, lol. They do have GPG .sig files now, so do they should announce it how to use it, as most other GNU projects. It's in the newer announce templates.

ambrop7 8y ago
I just pull GNU releases from https://ftp.gnu.org/gnu/ https://ftp.gnu.org/gnu/. One doesn't find HTTPS links in the official pages for some reason, but it exists.

verytrivial 8y ago

> Objdump's --disassemble option can now take a parameter, specifying the starting symbol for disassembly. Finally!

papaman 8y ago

A few days ago I tried "Linux from Scratch" (http://www.linuxfromscratch.org/ http://www.linuxfromscratch.org/) and I was learning about Binutils and the linux Toolchain. It's awesome to learn how important those core tools are for GNU/Linux.