stlink: patch incorrect calloc argument order

[jpteb]

With the update to GCC 14, stlink v1.8.0 is broken, as GCC 14 enforces the correct argument order of calloc (-Wcalloc-transposed-args). This commit adds a little patch to resolve the issue for now. This patch should be removed and stlink updated to the newest version that gets released. I've opened an issue in the stlink repository and am waiting for their response stlink-org/stlink#1444.

I have only performed minimal testing on the binaries, but I’d be very surprised if this patch causes any negative side effects.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[bjornfor]

Thanks! One nitpick: can you "fetchpatch" the patch instead?

[jpteb]

Thanks! One nitpick: can you "fetchpatch" the patch instead?

I'm not sure what you had in mind to be honest. I could also use their commits, but I was worried that might break something since I don’t know what has changed between v1.8.0 and now. Let me know if that works for you, or if I should use their commits instead. In that case, we could temporarily switch to their testing branch and revert to the tag once a new release is available.

[bjornfor]

Thanks! One nitpick: can you "fetchpatch" the patch instead?

I'm not sure what you had in mind to be honest. I could also use their commits, but I was worried that might break something since I don’t know what has changed between v1.8.0 and now. Let me know if that works for you, or if I should use their commits instead. In that case, we could temporarily switch to their testing branch and revert to the tag once a new release is available.

I thought the local patch was exported from the upstream git repo, but I see now that it isn't. Sorry for the confusion -- I think your original commit is fine.

[jpteb]

What do you think of this solution? It uses their commit and just pulls the file containing the swapped calloc arguments.

I think I like this solution the best.
This is my first time using fetchpatch, I didn't know it could do that.

[bjornfor]

Perfect, thanks!