-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Configure Windows builds #2
Configure Windows builds #2
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
…nda-forge-pinning 2023.04.13.00.04.50
Configure Windows builds on the feedstock.
@conda-forge-admin, please re-render |
…nda-forge-pinning 2023.04.13.00.21.25
Configuring to allow the packages to be downloaded from CI for debugging purposes. This should be reverted once it is no longer needed.
@conda-forge-admin, please re-render |
…nda-forge-pinning 2023.04.13.00.21.25
@conda-forge-admin, please re-render |
Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do. This message was generated by GitHub actions workflow run https://github.com/conda-forge/cuda-cudart-feedstock/actions/runs/4684345001. |
2faa695
to
b45dea8
Compare
Workaround to ignore Windows linking issues with `cuda-cudart` to get artifacts uploaded on CI. If a better fix is found, this should be reverted.
b45dea8
to
e5e7dac
Compare
For posterity attaching the Windows CI log and the artifacts produced on CI. |
@conda-forge-admin, please re-render |
…nda-forge-pinning 2023.08.24.19.16.55
Only linux files here
Alex think we need to raise an upstream issue about the missing libraries noted above ( #2 (comment) ). Would you be willing to pick this up? |
The libraries being installed seem to be sufficient to get nvcc working locally with these outputs. I think we should merge this and enable all nvcc packages in conda-forge/cuda-nvcc-impl-feedstock#5. If newer libraries are still needed upstream I can follow up on that after. |
Am not sure that is sufficient This library is linking to libraries outside the VC redist. It will be linked into everything built on Windows with CUDA support. Suspect this will cause issues building other packages down the line @isuruf do you have any thoughts here? How should we handle these libraries outside the redist? Can we add them to the redist? |
I checked and these DLLs are not found anywhere on the windows VM we have. There is a mention of the first DLL in https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis. Something about UWP apps calling win32 APIs. The other DLL is not mentioned in the docs at all. The two DLLs are in my wine installation, so they must be used by some apps. Is there anybody on the cudart team that you could talk to? Just ignoring the DLL here would probably result in downstream packages not working. |
Thanks Isuru & Alex! 🙏 If that's true, then maybe these libraries would make sense to list in some sort of Windows sysroot package Though am little confused as at least one of the libraries is in the redist (just with an older version), which suggests It would help to get some more from the |
Sounds like it was built with with VS2015 (14.0) and Windows 10 is the minimum OS. |
Did you read what I said? This makes no sense because the DLL is not found anywhere in a windows VM I checked. |
It was responding to what the In any event it sounds like you are disputing the |
Yes |
Ok, thanks Isuru 🙏 Could you please share how the VM was setup? We can share this info with the |
It's the OVH VM that we have access to |
@isuruf is this the Windows Server 2022 edition VM? I'm spinning up a node on OVH to test now. |
Andy & I paired up and tried looking at this issue on the lowest tier OVH machine. We tried to build the package there, but were running into issues with memory. So were not able to progress very far. Also we tried looking for the libraries listed above as well as ones that were in the redist, but actually were not finding any libraries (including ones from the redist on the machine). Andy has a local Windows machine on Windows 11 that he is going to start looking at. Have offered to help however I can there. We searched around on the web as well. Andy found this link, which mentions It is much harder to find info about One thing we might consider is going ahead and building this package so we can get to Must admit Windows is not my strong suit. So this is probably as far as I can go. |
I was able to get a Windows 11 machine to build this feedstock (after commenting out the missing_dso_whitelist lines). See the attached log. Additionally this library api-ms-win-core-libraryloader-l1-2-0.dll does not appear to be on my Windows 11 box either. I hope this allays @isuruf fears that accepting this patch would break all the other cuda dependencies. |
No, it doesn't. If you do I'm not sure why you are saying that things would work when you clearly say that the dependent DLL does not appear anywhere on your windows box. |
@isuruf thanks for the command to check. I ran it this morning and it throws the error. Our hypothesis was that this dll is only needed for older systems and there wouldn't be a linking. @jakirkham and I are not windows experts so we were trying to go through the process to validate the competing hypothesis in this thread. I've attached the log for folks to see. |
Okay it looks like these files are part of the Visual C++ Redistibution Package [0]. It looks like conda-forge already redistibutes some of win-core dlls, might be able to include those as well, e.g.
[0] https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-170 |
DLLs starting with I assume cudart was compiled with MinGW-w64 and MinGW-w64 emulates this mechanism as well. Therefore it's fine to ignore these two API sets. |
Thanks for the heads up! Definitely learned something new there. We will get it merged on Monday. |
@leofang recently pointed out offline that some CUDA 11 Windows libraries are also linking to the same API DLLs. Indeed those seem to be loading without issues. Though it was still unclear why that worked. Your explanation helps makes sense of that. Thanks Isuru! 🙏 |
Yes, I was puzzled when I inspected the old |
@conda-forge-admin, please re-render |
…nda-forge-pinning 2023.10.08.10.53.16
Co-authored-by: adibbley <103537006+adibbley@users.noreply.github.com>
@conda-forge-admin, please re-render |
…nda-forge-pinning 2023.10.08.10.53.16
Hi! This is the friendly conda-forge automerge bot! I considered the following status checks when analyzing this PR:
Thus the PR was passing and merged! Have a great day! |
@@ -25,13 +25,16 @@ source: | |||
|
|||
build: | |||
number: 6 | |||
skip: true # [osx or win] | |||
skip: true # [osx] | |||
|
|||
outputs: | |||
- name: cuda-cudart_{{ target_platform }} | |||
build: | |||
noarch: generic | |||
binary_relocation: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we know it was patchelf causing issues, perhaps it's time to remove this workaround?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK the patchelf
bug is not fixed: NixOS/patchelf#492
So no don't think we should be removing that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not fixed (I am fully aware), but we marked 0.18.0 as broken (you did it 🙂) and there's no 0.18.1 yet. I'd assume we are safe for now, and be extra cautious when a new patchelf is out.
We can even go further and pin patchelf globally, which I was surprised to see not done yet. We should consider it given its high impact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would rather not open us to unnecessary risk with patchelf
. This keeps us protected
We explored that before ( conda-forge/conda-smithy#1737 ), but there wasn't a good option to pursue ( conda-forge/conda-smithy#1737 (comment) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to add patchelf to conda-forge-pinning-feedstock, not conda-smithy. Is it not an option (and why)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unclear on how that would help. conda-forge-pinning
only affects dependencies in the requirements
of recipes themselves
Not build tools like patchelf
that are installed in base
(before the recipe is seen). This would require changes to conda-smithy
to work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, John, I see. I think this is where it confused me.
I know for a fact that installing patchelf to host could help ignore the one installed by conda-smithy. But it requires the recipe maintainer to manually add patchelf to host, which is something awkward that we don't want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And there would still be a patchelf
installed in base
that conda-build
would use. IOW the problem would still be there
Next steps will be to update the |
Fixes #1
Configure Windows builds of
cuda-cudart
.xref: conda-forge/staged-recipes#21723 (comment)
Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #1.
Here's a checklist to do before merging.