Support OS X. #46
Comments
|
For OpenCl an itermediate solution should be: #[cfg(not(target_os = "macos"))]
#[link(name = "OpenCL")]
#[cfg(target_os = "macos")]
#[link(name = "OpenCL", kind = "framework")]I am not sure if we can support the required linker arguments with the current structure of the crate. Before resolving those issues we could also provide a |
|
Thank you! Now I solved these only for mac by build.rs and could compiled both collenchyma and leaf. I am looking forward to your Mac support^^ |
|
Did you have to make any significant changes to the I think a short gist showing it would be nice for others to get it to run and as a base for a future PR. |
hobofan
changed the title
|
It may be difficult to make generic form because library path depends its environment and I wrote "hard-wired" code. I installed cuda via HomeBrew and wrote build.rs for collenchyma as below. And I succeeded to compile but failed framework_cuda_spec::it_allocates_4gb_memory_same_device test. And for leaf, I wrote build.rs as below, I am not quite sure why I need it here. It seems #[link(name = "OpenCL", kind = "framework")] in collenchyma may not work when a package (leaf) use it. This is all information that I have now. |
OSX Requires a -framework option to compile opencl FIX autumnai#46
OSX Requires a -framework option to compile opencl FIX autumnai#46
fix/opencl-framework fixes building for OSX OSX Requires a -framework option to compile opencl FIX #46
|
Might have been resolved by #52. Feedback if it's working without a |
|
This is not working for me without a build.rs, I receive a build failure when ld cannot find Note that when we do get this working it should be possible to test it on travis by adding |
|
@y-ich hmm, I tried your proposed workaround and I still cannot get a clean compile, here's my attempted build.rs: fn main() {
println!("cargo:rustc-link-search=native=/usr/local/cuda/lib");
}failure: I have cuda installed via homebrew at |
|
So @hobofan and I just bounced some ideas on how to solve the build errors that keep popping up due to the third-party libraries (mostly CUDA, though). There are two problems that we need to solve: the linking problem at build time and the linking problem at run time. Linking at build time One of the biggest problems is, which also causes most of the issues we receive, that different platforms have different locations for their CUDA library. This causes a lot of confusion and makes the issues hard to debug as it requires to be on that platform. (e.g. we can't really recreate OSX issues). Few days ago we spoke to NVIDIA, and learned, that their libraries are available via a direct download link, which can help to solve the linking at build time situation. Our proposed plan forward is, creating a X-sys crate, which takes care of downloading/linking to the expected X library. This should work on any platform with no to very little platform adjustment. Now, that we know where the libraries are located, the build time linking is working reliable on any platform. Linking at run time As we would download the libraries in the build process to an artifical directory, there is definitly no way that Two solutions for the run time linking
Feedback to the proposed solution is highly welcome. So far, this is our current take on how we would solve the build error issues. @reem I did not know that this was possible with Travis - I like the idea. And with the download links from NVIDIA, (I think) this could be tested in a 'real' environment. |
|
One thing to keep in mind about possibly testing on travis is I'm not sure if the nodes actually have access to a GPU (I doubt it). That sounds like a pretty good plan, I would suggest having a check for an already installed system library before downloading every time (downloading every time can be very slow), and also statically linking as much as possible to simplify deployment. Anything I can do here to help get this working? I spun up a debian instance last night on GCE to get a linux dev environment going only to discover that GCE doesn't support GPU nodes... |
The newly-added build script adds the default installation location of cuda to rustc's library search path. Fixes autumnai#46
The newly-added build script adds the default installation location of cuda to rustc's library search path. Fixes autumnai#46
|
Ohhh, this is unfortunate :) AWS has GPU nodes and Azure should have them since Dec, too. (although the comments say, it didn't launch yet). But first, thanks for the PR to fix it on OSX - very much appreciated. I like the .travis.yml file but would try to already implement the basic concepts of the proposed build time approach, before merging it into master. (Skipping, for now, the X-sys crate part). Including the checking for already downloaded files on the machine and the download fallback in cases where the files couldn't be found. I will write some more details regarding the PR there at #59 |
|
Building OSX with |
chore/osx: support building on os x and test this on travis The newly-added build script adds the default installation location of cuda to rustc's library search path. Fixes #46
|
Please excuse me if this is a dumb question but is the OSX support in collenchyma = "0.0.8" already? I tried getting the example in the README to work but it (still) fails with |
Hi.
I did "cargo test" on my Mac and failed by the following error.
Changing the code in src/frameworks/opencl/ffi.rs from
to
solved the problem though I have no idea to support both linux and macos.
Next I got the following error
I had installed cuda via HomeBrew.
So it seems I need to pass library path to the linker.
I tried link_args attribute in src/frameworks/cuda/api/ffi.rs, and rustc-link-search in Cargo.toml, but failed.
I will be happy if the library supports OS X.
The text was updated successfully, but these errors were encountered: