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

libcublas-dev should depend on cuda-crt-dev_* #8

Open
adibbley opened this issue Apr 6, 2023 · 13 comments
Open

libcublas-dev should depend on cuda-crt-dev_* #8

adibbley opened this issue Apr 6, 2023 · 13 comments
Assignees

Comments

@adibbley
Copy link
Contributor

adibbley commented Apr 6, 2023

cublas headers depend on cudart headers, which depend on nvcc (crt) headers. We should add these dependencies once those packages are available.

@bdice
Copy link
Contributor

bdice commented Apr 6, 2023

When compilers are available, we can also add tests that compile a sample executable (but can't run it without a GPU). Suggesting this, which was proposed by @robertmaynard.

// test.cpp
#include <cublas_v2.h>

int main() {
    cublasStatus_t stat;
    cublasHandle_t handle;
    stat = cublasCreate(&handle);
    return stat != CUBLAS_STATUS_SUCCESS;
}

Then we'd depend on compilers in the test and execute something like g++ -I... -lcublas test.cpp.

@jakirkham
Copy link
Member

Since {{ compiler("cuda") }} is going to be needed as a requirement/build by any recipe build CUDA packages, this should be picked up via cuda-nvcc. If not, we may need to tweak the dependencies of cuda-nvcc and/or cuda-cudart to make sure that is happening

@bdice
Copy link
Contributor

bdice commented Apr 11, 2023

That’s fine for downstream recipes, but we still need these requirements on the libcublas recipe if users are building applications from source with libcublas.

@jakirkham
Copy link
Member

jakirkham commented Apr 11, 2023

Maybe I'm missing something.

Thought this was for libcublas-dev. Understand mitigating the libcublas dlopen issue ( #9 ) requires a runtime dependency.

How is a runtime dependency used here?

@robertmaynard
Copy link

How is a runtime dependency used here?

The headers of libcublas require headers from cuda-cudart-dev ( cuda_runtime.h) which requires headers from cuda-nvcc ( crt/host_defines.h ).

So to compile/use libcublas with a C or C++ compiler you still need the above packages installed to include cublas.h.

@jakirkham
Copy link
Member

cc @billysuh7 (to look into this further)

@jakirkham
Copy link
Member

Now that the CRT headers are split out of NVCC as of CUDA 12.2 ( conda-forge/cuda-nvcc-feedstock#32 ), this should be doable

It sounds like cudart is not needed for cuBLAS. So that doesn't need to be added (confirmed by running ldd on libcublas.so to check for libcudart linkages)

In terms of cuBLAS packages, these make most sense to add to the -dev packages

@bdice
Copy link
Contributor

bdice commented Jul 31, 2024

@jakirkham Running ldd doesn’t check for dlopen, right? Is there a possibility of libcudart being dlopened, like nvrtc in #9?

Ultimately I think only library maintainers can provide accurate dependency lists, ldd is “necessary but not sufficient” for accuracy.

@leofang
Copy link
Member

leofang commented Jul 31, 2024

All math libs must link to cudart statically. It's a requirement.

@bdice
Copy link
Contributor

bdice commented Jul 31, 2024

Great, then I agree we can make progress on this when someone has time.

@billysuh7 billysuh7 self-assigned this Jul 31, 2024
@billysuh7
Copy link

I will take this. Thanks.

@jakirkham
Copy link
Member

Should add the above comment ( #8 (comment) ) was a summary of our discussion in the meeting yesterday ( with feedback from @adibbley and @robertmaynard )

@jakirkham jakirkham changed the title libcublas-dev should depend on cuda-nvcc and cuda-cudart-dev libcublas-dev should depend on cuda-crt-dev_* Jul 31, 2024
@jakirkham
Copy link
Member

Retitled the issue to hopefully make this clearer

Thanks Billy! 🙏

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

No branches or pull requests

6 participants