shark: fix build with boost187

[tobim]

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.

[daspk04]

Hi @tobim !

Thanks for the fix.

The official otb package seems to be using boost version 1.86.0, given that shark will have no official release and more likely to be used only while building otb (not sure if anyone would be using shark package), will it make sense to fix the boost version to 1.86.0 ?

[tobim]

will it make sense to fix the boost version to 1.86.0 ?

I believe pinning to a specific version of a library that does not explicitly support multi-versioning at runtime it not something that should be done in libraries, no matter how obscure they are.

We can fix otb in another PR, I believe support for current boost has already been merged upstream, but swig is giving me trouble.

[daspk04]

Thanks @tobim !