Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

haskellPackages.libtorch-ffi: Fix the link to libtorch #367998

Merged
merged 2 commits into from
Jan 3, 2025

Conversation

junjihashimoto
Copy link
Member

@junjihashimoto junjihashimoto commented Dec 24, 2024

  • Fix the broken hasktorch.

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

@junjihashimoto junjihashimoto changed the title haskellPackages.hasktorch: 0.0.1.0 -> 0.2.1.0 haskellPackages.hasktorch: 0.0.1.0 -> 0.2.1.1 Dec 24, 2024
@junjihashimoto
Copy link
Member Author

Can we make changes like this PR in maintainers/scripts/haskell?

@ofborg ofborg bot added 8.has: clean-up 8.has: package (new) This PR adds a new package labels Dec 25, 2024
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with haskell packages infra really, but the first line of the file says: /* hackage-packages.nix is auto-generated by hackage2nix -- DO NOT EDIT MANUALLY! */. I presume there should be some other place for applying overrides?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is the place? pkgs/development/haskell-modules/replacements-by-name/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe pkgs/development/haskell-modules/configuration-nix.nix is the better tool, I see that libGL related patches and configurations are applied there

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your review! I'll check the place.

Comment on lines 144155 to 144165
configureFlags = [
"--extra-include-dirs=${lib.getDev pkgs.libtorch-bin}/include/torch/csrc/api/include"
] ++ lib.optionals pkgs.config.cudaSupport [ "-f cuda" ];
}) ({
c10 = pkgs.libtorch-bin;
torch_cpu = pkgs.libtorch-bin;
torch = pkgs.libtorch-bin;
} // lib.optionalAttrs (pkgs.config.cudaSupport) {
torch_cuda = pkgs.libtorch-bin;
});

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason to choose the wheel package over the real build from python3Packages.torch?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK python3Packages.torch uses pre-cxx11 ABI. It needs the extra option for compiling and linking.
So it uses the libtorch.

Copy link
Member Author

@junjihashimoto junjihashimoto Dec 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK python3Packages.torch uses pre-cxx11 ABI. It needs the extra option for compiling and linking.
So it uses the libtorch.

Huh. I wonder if we should introduce another attribute for cxx11-abi source-built torch, or just make cxx11-abi the default. "There are no stupid questions", but: could the latter cause symbol collisions with other native extensions? The new attribute, otoh, could be named libtorch to contrast it with libtorch-bin. We definitely should do one of the two, but not in this PR

Copy link
Member Author

@junjihashimoto junjihashimoto Jan 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For other native extensions of pytorch, we need to add a cmake option not to use cxx11-abi, otherwise symbol conflicts will occur.
gcc and clang use cxx11-abi by default.
I think it's good that cxx11-abi libtorch is the default, because users don't have to specify any options.
I don't think libtorch users are also native extension users, so I'm not sure if the two options are necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For other native extensions of pytorch

Well yes we use extensions like torchaudio with the same variant of pytorch we compile it against, incl. the same version of the cuda stack. But I rather meant, other extensions like opencv4, zeromq, etc, etc that use libstdc++.

Bottom line: would be nice for us at some point to investigate moving hasktorch from libtorch-bin to source-build torch

@sternenseemann
Copy link
Member

Indeed, hackage-packages.nix may not be edited manually. You can re do your PR based on the haskell-updates branch where haskellPackages.hasktorch already points to the 0.2.1.1 version. Small modifications and fixes can be done via overrides in configuration-common.nix (for temporary workarounds) and/or configuration-nix.nix (for fixes that will always be necessary in nix(pkgs)). There are also platform and compiler specific files if need be.

@github-actions github-actions bot added the 8.has: documentation This PR adds or changes documentation label Dec 28, 2024
@junjihashimoto junjihashimoto changed the base branch from master to haskell-updates December 28, 2024 08:47
@github-actions github-actions bot removed the 8.has: documentation This PR adds or changes documentation label Dec 28, 2024
@junjihashimoto junjihashimoto changed the title haskellPackages.hasktorch: 0.0.1.0 -> 0.2.1.1 haskellPackages.hasktorch: 0.2.0.1 -> 0.2.1.1 Dec 28, 2024
@junjihashimoto
Copy link
Member Author

junjihashimoto commented Dec 28, 2024

@SomeoneSerge @sternenseemann Thank you for great help!
It moved to configuration-nix.nix.
For now, hasktorch in the hackage is 0.2.0.1 not 0.2.1.1, so I updated the version in configuration-nix.nix.
In my environment, it works on both macos and linux with CUDA.

[junji-hashimoto@nixos:~/git/nixpkgs]$ nix repl
Welcome to Nix 2.18.2. Type :? for help.

nix-repl> :l .
Added 23376 variables.

nix-repl> :u haskellPackages.ghcWithPackages (pkgs: with pkgs; [hasktorch])

[nix-shell:~/git/nixpkgs]$ ghci
GHCi, version 9.6.6: https://www.haskell.org/ghc/  :? for help
ghci> import Torch
ghci> a0 = toCUDA $ ones' [3,3]
ghci> a0 * a0
Tensor Float [3,3] [[ 1.0000   ,  1.0000   ,  1.0000   ],
                    [ 1.0000   ,  1.0000   ,  1.0000   ],
                    [ 1.0000   ,  1.0000   ,  1.0000   ]]

@sternenseemann
Copy link
Member

I assume 0.2.1.1 fixes some issue 0.2.0.1 still exhibits? I think the manual upgrades will be obsolete soon, we'll have to bump hackage again soon for unrelated reasons.

@junjihashimoto
Copy link
Member Author

The 0.2.0.1 has an issue of cabal file and no support for Apple GPU.

@junjihashimoto
Copy link
Member Author

junjihashimoto commented Dec 28, 2024

It might be better to remove the version and wait for the update. For now, the test will fail though.

@junjihashimoto junjihashimoto changed the title haskellPackages.hasktorch: 0.2.0.1 -> 0.2.1.1 haskellPackages.libtorch-ffi: Fix the link to libtorch Dec 28, 2024
@junjihashimoto
Copy link
Member Author

It removed the versions of hasktorch and libtorch-ffi.

@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1 and removed 10.rebuild-darwin: 1-10 labels Dec 29, 2024
@@ -388,6 +388,10 @@ self: super: ({
http-reverse-proxy = dontCheck super.http-reverse-proxy;
servant-auth-server = dontCheck super.servant-auth-server;

sysinfo = overrideCabal (orig: {
doCheck = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are doCheck / dontCheck helpers in haskell.lib.

Also is this a bitflip? Don’t you want to disable the test?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be sysinfo = dontCheck super.sysinfo here, as it used to be doCheck = !…isDarwin.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maralorn @sternenseemann
It was wrong. Thanks for pointing that out. I've fixed it.

@maralorn maralorn merged commit d3780c9 into NixOS:haskell-updates Jan 3, 2025
22 of 23 checks passed
@junjihashimoto junjihashimoto deleted the feature/hasktorch branch January 5, 2025 05:54
@sternenseemann
Copy link
Member

@junjihashimoto In #371032, haskell.packages.ghc96.hasktorch works again (though it is incorrectly marked as broken currently). Unfortunately, we got an unlucky timing and don't have libtorch-ffi-helper >= 2.0.0.1 which would also support GHC 9.8 (which is the new default).

@junjihashimoto
Copy link
Member Author

@sternenseemann
The latest versions of hasktorch-0.2.1.2, libtorch-ffi-2.0.1.2, and libtorch-ffi-helper-2.0.0.1 support ghc9.8.
https://github.com/hasktorch/hasktorch/pull/718/files

@junjihashimoto
Copy link
Member Author

I will make it possible to build hasktorch at the nightly stage before the LTS is released.

@sternenseemann
Copy link
Member

@sternenseemann The latest versions of hasktorch-0.2.1.2, libtorch-ffi-2.0.1.2, and libtorch-ffi-helper-2.0.0.1 support ghc9.8. https://github.com/hasktorch/hasktorch/pull/718/files

Yes, I saw that! I've made a note to remove the broken flag when we have that version. hasktorch can be used on the haskell-updates branch now via GHC 9.6: d5ca2c9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants