-
Notifications
You must be signed in to change notification settings - Fork 93
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
conda-build: Add 'windows-latest' to conda build workflow #449
Conversation
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
c17d9b8
to
9fdbc4a
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
10b76c3
to
2509a50
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
lz4 is currently not resolved on Windows when building for conda-forge. This improves the resolution of LZ4, making it available for this configuration. Signed-off-by: Julien Jerphanion <[email protected]>
747f99f
to
89234b2
Compare
Yes. Signed-off-by: Julien Jerphanion <[email protected]>
89234b2
to
fdc41ec
Compare
This should remove the following error met with MSVC 14.29.30133: ``` D:\a\ArcticDB\ArcticDB\cpp\arcticdb/storage/storages.hpp(75): error C7510: 'KeyNotFoundException': use of dependent type name must be prefixed with 'typename' ``` See: https://github.com/man-group/ArcticDB/actions/runs/5177504090/jobs/9327681067#step:6:374 Signed-off-by: Julien Jerphanion <[email protected]>
2374b5f
to
83a7943
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
83a7943
to
081453e
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
pcre cannot be linked on Windows for now, eventhough it apparently is resolved. There's no CMake configuration for the version of pcre distributed on conda-forge for Windows. conda-forge/pcre-feedstock#24 is improving the build for Windows regarding CMake. |
Signed-off-by: Julien Jerphanion <[email protected]>
146d2b7
to
f67d0af
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
64acc86
to
9ad10cb
Compare
Reason: needed for python 3.6 which we do not build packages for on conda-forge. Also try not to install dependencies via install_requires. Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
f8833b5
to
9ad57b0
Compare
I tried many things but I still obtain linker errors for the generated sources of the Those errors are due to symbols that are present in the object files of the generated source but that are missing in the shared library of protobuf. There are 5 missing symbols:
The following is used:
Missing symbols for similar configurations also have been reported in some currently open issues of
All linker errors
|
versions for packages on conda-forge for protobuf 3 The protobuf 4 compilation will also be perform, but we ignore this part for the moment just to be able to compile for 3 and see if this works.
9ad57b0
to
39cdb1f
Compare
The linker fails to find symbols eventhough they are present in both `libprotobuf.dll` and the `libprotobuf.lib`. This has been checked: - `protoc` and `libprotobuf` have the same version (3.20.3) - the linker call for the ultimate target, `arcticdb_ext`, correctly contains the path to `libprotobuf.lib` - `arcticdb_core_static` links successfully while containing the objects of the C++ source files generated by `protoc` - the presence of the 5 symbols reported as "missing" has been checked with `dumpbin` and Dependencies [1] and they are present as exported in both `libprotobuf.dll` and `libprotobuf.lib`. This has been tried: - using `OBJECT` for building intermediary targets. This has not been tried: - checking toolchains and ABI version compatibility with conda-forge's - creating an executable which depends on `arcticdb_core_static` observing if any other specific problems occurs This commit removes the dependence on `libprotobuf-lite` which is redundant with `libprotobuf`. 1: https://github.com/lucasg/Dependencies 2: https://protobuf.dev/support/version-support/#python
39cdb1f
to
d00fbd5
Compare
Potential cause of failure to have a look at: the packaging of abseil and libprotobuf on conda-forge. |
I haven't looked at the issues here, but the only hard requirement you need w.r.t. this ATM is to compile with C++17 (or perhaps C++20). |
We already compile with C++17, the problem lies in the code-base with some code for headers being inlined unusually via macros (I did have time to have a look at that yet). @Klaim might be able to give more details in this regard. |
From memory (didnt get back to this yet): The issue is that the symbols that should be generated for the objects coming from compiling the protobuf-generated code are correctly generated but for some reason they are not found on linking. |
Failures might be related to conda-forge/libprotobuf-feedstock#201. |
99b14c5
to
d8c1193
Compare
Signed-off-by: Julien Jerphanion <[email protected]>
Signed-off-by: Julien Jerphanion <[email protected]>
Closing for now, see #1412. |
Reference Issues/PRs
Follow-up of #318.
Towards #190.
What does this implement/fix? Explain your changes.
Add Windows to the conda build workflow.
Any other comments?
It is willingly breaking other configurations on the CI to find one that works for Windows on conda-forge.