suitesparse: rename fixDarwinDylibNames override

[graham33]

Motivation for this change

This seems to prevent shadowing the regular fixDarwinDylibNames function, which is a nativeBuildInput. Without this change some dylibs still had relative paths embedded. It's possible something deeper is happening, but this change fixed the issue for me. See #96981 for details.

Fixes #96981

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[jtojnar]

According the comment, we might be able to remove the whole postInstall and fixDarwinDylibNames.

[ttuegel]

According the comment, we might be able to remove the whole postInstall and fixDarwinDylibNames.

That would be better. I don't have a Darwin machine to check, maybe @graham33 could? Still, these changes look reasonable to me, and I'm fine with merging them if they fix the problem.

[graham33]

Yes I think this works, just rebuilding to test. Thanks.

[graham33]

I successfully built and ran octave against the updated commit.

[jtojnar]

Thanks for testing. Is it also okay to remove fixDarwinDylibNames from dependencies?

[graham33]

I think we still need fixDarwinDylibNames in general, if I remove it entirely we get libraries with relative references, e.g.:

otool -L /nix/store/sx5p4mwhkxxhd2zwm8y7yz1di1abfl1a-suitesparse-5.7.2/lib/libcholmod.dylib                                                 
/nix/store/sx5p4mwhkxxhd2zwm8y7yz1di1abfl1a-suitesparse-5.7.2/lib/libcholmod.dylib:
...
	libamd.2.dylib (compatibility version 2.0.0, current version 2.4.6)
...

vs this with fixDarwinDylibNames still in nativeBuildInputs:

otool -L /nix/store/amyna7fbzk3ag3yp7ghj441fbaq36kpi-suitesparse-5.7.2/lib/libcholmod.dylib 
/nix/store/amyna7fbzk3ag3yp7ghj441fbaq36kpi-suitesparse-5.7.2/lib/libcholmod.dylib:
...
	/nix/store/amyna7fbzk3ag3yp7ghj441fbaq36kpi-suitesparse-5.7.2/lib/libamd.2.dylib (compatibility version 2.0.0, current version 2.4.6)
...

I don't know much about Darwin dylibs, but I think absolute store paths are what we want (and these were the source of the problems I had with Octave).