2.10.0.rc1 #260
2.10.0.rc1 #260
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 ( I do have some suggestions for making it better though... For recipe:
|
|
@conda-forge-admin, please rerender |
…nda-forge-pinning 2022.08.04.07.32.40
|
@hmaarrfk @h-vetinari I lost track of what is ready for c++17 and what is not. The cuda11x builds are failing with c++17 errors. As you see below the compiler call includes c++17, but the error is obviously c++17 specific. It could be something else bringing c++14 (or something else) with it? Any advice? How to make sure cuda11x builds actually work/compile with c++17? |
Not gonna bother with fixing this...
Error in fail: The following libraries cannot be linked either statically or dynamically:
@cub_archive//:cub
To ignore which libraries get linked statically for now, add the following to 'static_deps':
"@cub_archive//:__subpackages__",
…nda-forge-pinning 2022.08.04.07.32.40
|
The recipe currently contains both: as well as which seems contradictory.
the abseil shared builds should be C++17 already. Based on the error you pasted, it's that the code itself depends on a C++17 facility ( |
it's largely okay, but should not be there for future iterations, so fixed it
yep, see I think we will need to work on this custom toolchain, I may need to get the actual package finally and apply fixes globally... good points, also the nvcc constrains break stuff |
…nda-forge-pinning 2022.08.04.07.32.40
|
Maybe we will finally manage to build on the CI??? LOL integrating in #261 |
|
The conclusion from this: We will be ready once 2.10 is out, but we we need to fine-tune both the custom_toolchain and our deps (e.g. protobuf and libprotobuf). I will leave these PRs (this and #261) open for a bit longer and then I will close them. |
|
Thanks a lot for your work on this! Very timely, as previously. 🙃
Why close them if we can take them as the basis for iterating? What protobuf changes are necessary? C++17 builds? |
I am not sure still. The error is clearer in the jaxlib feedstock conda-forge/jaxlib-feedstock#122 and I think it is related. I suspect we cannot build with 3.20 and we have to pin to lower than that. Or, as recommended by the jax people, bundle it altogether since different libraries (e.g. jax, tensorflow, etc.) reexport the shared symbols and then they clash and segfaults. That has serious implications for other shared libraries (e.g. zlib) as you can see from the history of my tries to figure out the jaxlib problems We also have problems with cuda 11.1 for some bizarre reason, I will investigate later if it actually carries to 11.2 and 11.0 (I disabled 10.2 completely). If the tensorflow team moved like the JAX team did, then we will likely should only build 11.2+ going forward. (Most jax builds <11.2 failed.) I will keep looking into the commit history to see what, if any, clues are there about this Yes, we can keep them open :) I am just allergic to keep things hanging, I like the sense of "completeness" when things are closed, but let's keep them open since we can reuses them for rc1 and rc2 (as applicable) |
|
Ugh, symbol re-exporting is just blech. If it's not your lib, don't provide the symbols (vendoring something and using it internally is one thing, but seizing other project's symbol namespaces quite another). |
|
FYI This actually fails with an eerily similar error to conda-forge/jaxlib-feedstock#122 something about abseil, grpcc, and protobuf Will truncate and post the error message |
|
Didn't allow me to post the error, so: https://gist.github.com/ngam/bcaf0a446e260f1bd43788dc2e411d51 |
|
@h-vetinari @hmaarrfk let me know if the errors look familiar to you at all. It seems to me either:
|
|
The linker not finding the destructor reminds me of problems I had during conda-forge/sentencepiece-feedstock#26, and the stuff that shows up as missing virtual functions on windows. This answer might be relevant. Beyond that, I'd use the newest abseil builds, and also try the static ones matching the C++ version used to compile tf |
newest abseil builds did the trick, thanks!!! We need to pin both jaxlib and tensorflow at abseil 2022 going forward. |
|
closing in favor of #264 |
notable changes:
MAJOR CHANGES:
: RIP cuda102 (I am not going to bother looking into this)
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)