GNU Binutils 2.32 Released | Hacker News Reader

GNU Binutils 2.32 Released

sourceware.org

66 pointsedelsohn26 comments

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).

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.

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.

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.

With the current level of traffic (tens of commits a day on master) it would be within pocket money budget as well.

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.

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.

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.

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)

> 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

"Don’t just stand around saying somebody should do something: Be someone"

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

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!

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.

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.

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.

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?

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

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.

> 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.

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

C-SKY Orange PI board is quite nice and cheap. We added C-SKY support in radare2 too.

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"

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

Finally!

A few days ago I tried "Linux from Scratch" (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.

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.

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

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

Reply on news.ycombinator.com