Closed kkraus14 closed 2 years ago
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 (recipe
) and found it was in an excellent condition.
@conda-forge-admin, please rerender
2022-04-25T15:23:58.2451571Z /home/conda/feedstock_root/build_artifacts/nvcc_1650900156699/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin/x86_64-conda-linux-gnu-c++: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/conda/feedstock_root/build_artifacts/nvcc_1650900156699/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin/x86_64-conda-linux-gnu-c++)
I'm guessing this is something busted with our custom conda_build_config.yaml
but I'm unclear unless we're using outdated docker images?
It looks like the latest gcc / gxx 7.5 packages were built on cos7, where cos6 is no longer really supported. In order to get passing builds on 9.2 - 10.2 needed to move to the cos7 images.
@conda-forge-admin, please rerender
@isuruf, do you what is going on here ( https://github.com/conda-forge/nvcc-feedstock/pull/80#issuecomment-1108730100 )? No worries if not
@jakirkham @leofang any issues with moving forward with the cos7 changes? Given this is just a shell script anyway? I have the sense that more and more cos6 issues are going to trickle down where I'm not sure it's worth the pain of us dealing with them for this package.
I don't see any concern here, though I am not sure what issue using -I
would cause either. But I'm fine merging it.
Thanks @leofang!
Yeah sorry ok with me too. Just wanted to flag that issue since it is a bit odd
I don't see any concern here, though I am not sure what issue using
-I
would cause either. But I'm fine merging it.
It changes how tools like clang-tidy
interact for one thing, and then libraries like thrust
and cub
are included in the folder where a user might want to specify a different version than what's included in the toolkit.
The primary issue with this approach is that by using CXXFLAGS
etc with -I
we are setting the first includes therefore overriding any the user has specified. We could use -idirafter
to set an include that will be searched after the -I
and -isystem
.
I don't know if clang-tidy understands the idirafter
option
Edit:
Using idirafter
also makes sure we don't override any -isystem
includes that the project has. The primary occurence I can think of is when CMake adds includes from a imported target ( e.g. find_package
call) those are all system includes.
Checklist
0
(if the version changed)conda-smithy
(Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)Fixes #79