-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Add setuptools
to requirements/host
#68
Add setuptools
to requirements/host
#68
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 2022.10.26.15.31.17
@mbargull, can you please review? 🙂 |
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.
LGTM, thanks!
This will help to make builds fail early for new Pythons with https://github.com/numba/llvmlite/blob/v0.39.1/setup.py#L49 .
Missed |
I think just |
Thanks Marcel! 🙏 Let's just do |
setuptools
& wheel
to requirements/host
setuptools
to requirements/host
Hi! This is the friendly conda-forge automerge bot! I considered the following status checks when analyzing this PR:
Thus the PR was not passing and not merged. |
No idea yet about the failing Windows builds @@ -1,31 +1,31 @@
## Package Plan ##
- environment location: D:\bld\llvmlite_1662374438112\_h_env
+ environment location: D:\bld\llvmlite_1666809933100\_h_env
The following NEW packages will be INSTALLED:
bzip2: 1.0.8-h8ffe710_4 conda-forge
- ca-certificates: 2022.6.15-h5b45459_0 conda-forge
+ ca-certificates: 2022.9.24-h5b45459_0 conda-forge
libffi: 3.4.2-h8ffe710_5 conda-forge
- libiconv: 1.16-he774522_0 conda-forge
- libllvm11: 11.1.0-hab3b255_3 conda-forge
- libsqlite: 3.39.2-h8ffe710_1 conda-forge
- libxml2: 2.9.14-hf5bbc77_4 conda-forge
- libzlib: 1.2.12-h8ffe710_2 conda-forge
- llvm: 11.1.0-h6fda50d_3 conda-forge
- llvm-tools: 11.1.0-ha327e53_3 conda-forge
- llvmdev: 11.1.0-hab3b255_3 conda-forge
- openssl: 3.0.5-h8ffe710_1 conda-forge
+ libiconv: 1.17-h8ffe710_0 conda-forge
+ libllvm11: 11.1.0-h97333cc_4 conda-forge
+ libsqlite: 3.39.4-hcfcfb64_0 conda-forge
+ libxml2: 2.10.3-hc3477c8_0 conda-forge
+ libzlib: 1.2.13-hcfcfb64_4 conda-forge
+ llvm: 11.1.0-h6fda50d_4 conda-forge
+ llvm-tools: 11.1.0-hf00eed6_4 conda-forge
+ llvmdev: 11.1.0-h97333cc_4 conda-forge
+ openssl: 3.0.5-hcfcfb64_2 conda-forge
python: 3.10.6-hcf16a7b_0_cpython conda-forge
+ setuptools: 65.5.0-pyhd8ed1ab_0 conda-forge
tk: 8.6.12-h8ffe710_0 conda-forge
- tzdata: 2022c-h191b570_0 conda-forge
- ucrt: 10.0.20348.0-h57928b3_0 conda-forge
- vc: 14.2-hb210afc_7 conda-forge
- vs2015_runtime: 14.29.30139-h890b9b1_7 conda-forge
+ tzdata: 2022e-h191b570_0 conda-forge
+ ucrt: 10.0.22621.0-h57928b3_0 conda-forge
+ vc: 14.3-h3d8a991_9 conda-forge
+ vs2015_runtime: 14.32.31332-h1d6e394_9 conda-forge
xz: 5.2.6-h8d14728_0 conda-forge
- zlib: 1.2.12-h8ffe710_2 conda-forge
-
+ zlib: 1.2.13-hcfcfb64_4 conda-forge
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
@@ -34,13 +34,13 @@
## Package Plan ##
- environment location: D:\bld\llvmlite_1662374438112\_build_env
+ environment location: D:\bld\llvmlite_1666809933100\_build_env
The following NEW packages will be INSTALLED:
- cmake: 3.24.1-h39d44d4_0 conda-forge
- ucrt: 10.0.20348.0-h57928b3_0 conda-forge
- vs2015_runtime: 14.29.30139-h890b9b1_7 conda-forge
- vs2019_win-64: 19.29.30139-hb9aee9d_7 conda-forge
+ cmake: 3.24.2-h1537add_0 conda-forge
+ ucrt: 10.0.22621.0-h57928b3_0 conda-forge
+ vs2015_runtime: 14.32.31332-h1d6e394_9 conda-forge
+ vs2019_win-64: 19.29.30139-hb9aee9d_9 conda-forge
vswhere: 3.0.3-h57928b3_0 conda-forge Only somewhat significant change seems to be conda-forge/llvmdev-feedstock#171 |
Hmm...on Windows CI there are lots of errors that look like this: LLVMBinaryFormat.lib(Magic.cpp.obj) : error LNK2001: unresolved external symbol __std_system_error_allocate_message [%SRC_DIR%\ffi\build\llvmlite.vcxproj]
...
LLVMInstrumentation.lib(CGProfile.cpp.obj) : error LNK2001: unresolved external symbol __imp___std_init_once_begin_initialize [%SRC_DIR%\ffi\build\llvmlite.vcxproj]
...
LLVMInstrumentation.lib(GCOVProfiling.cpp.obj) : error LNK2019: unresolved external symbol __std_reverse_copy_trivially_copyable_1 referenced in function "private: void __cdecl `anonymous namespace'::GCOVProfiler::emitProfileNotes(void)" (?emitProfileNotes@GCOVProfiler@?A0x15c6988e@@AEAAXXZ) [%SRC_DIR%\ffi\build\llvmlite.vcxproj] |
Hi! This is the friendly conda-forge automerge bot! Commits were made to this PR after the |
Don't think it would be |
No idea. It seems to work with the old LLVM build (number 3). The changes from build 3 to build 4 are the added patches but also vs2017 -> vs2019: |
cc @h-vetinari (in case you have thoughts on the Windows build issue here 🙂) |
What am I looking for here? The CI appears to be green? 🤔 |
I looked for the LNK2001 errors mentioned above in the build logs, but didn't find them (also, if there are linker errors, those should definitely fail the build) |
The last commit is just a temporary one that uses a pinned down previous LLVM build. |
My and John's guess is that it has to do with mismatched VS 2017/2019 builds. |
Phew, LLVM 11.1 is just when I started getting involved with the LLVM stack - almost 2 years ago. 😅 Based on the missing symbols and a bit of googling, it seems from this SO post that recompiling everything with a consistent toolchain (down to the minor/patch version) might solve it. Considering that there have been some changes to the vc- & ucrt- feedstocks in the meantime, it might be worth trying to rebuild LLVM 11.1 again. But I'm really grasping at straws here. Perhaps @isuruf has deeper insights. |
We did rebuild LLVM 11.1 recently ( conda-forge/llvmdev-feedstock#171 ). This was to fix some issues users were seeing with Numba on macOS M1 ( numba/numba#8215 ) (though maybe elsewhere as well). Notice that in the LLVM 11.1 PR Windows VS upgraded from 2017 to 2019. Wonder if that might not be supported by LLVM 11.1. We could rebuild (reverting that Windows change). Or we could also just pull those Windows packages. Wanted to ask first though to make sure there isn't something we are missing about how VS and LLVM interplay |
Yes, I saw. Based on what I found, it might make sense to rebuild that branch again, due to the (minor, but still) changes in the last month. I don't think LLVM 11.1 is incompatible with VS2019, but I have nothing against pulling those builds if it helps you. |
Submitted PR ( conda-forge/llvmdev-feedstock#185 ) to bump the build number of LLVM 11.1 |
f840ba5
to
055c0cd
Compare
Fail with the new build too :/. So do yet another rebuild of # conda_build_config.yaml
cxx_compiler: # [win]
- vs2017 # [win] ? |
Looks like this passes with the |
Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #67.
Here's a checklist to do before merging.
Fixes #67