Conversation
|
Replaces #8483 |
7e7b18a to
29ca836
Compare
5b63415 to
e8ac9ed
Compare
* Added mingw32 patch: To make posix_memalign etc. available on mingw32. * Dropped CUDA archs 60, 61 for CUDA 11.8+. * Update CMake wrt. CUDA arch detection: https://github.com/Kitware/CMake/blob/v3.23.3/Modules/CMakeDetermineCUDACompiler.cmake#L654 * Fixed CUDA cmake configure: Added symlink from $prefix/cuda/lib64 to $prefix/cuda/lib * Updated to v1.9.0 * Added header file products * Added additional patches for mingw32
e8ac9ed to
70c112e
Compare
This reverts commit 9fc05ef.
…one `configure` as it seems to not be needed for CUDA 11.8 and CUDA 12.1
|
@giordano Did something happen to powerpc64le support in OpenBLAS32? |
|
Yes, OpenBLAS 0.3.28 doesn't support PowerPC with libgfortran 3 and 4 |
|
Ah yes, I found a385efd What would be the proper approach here?
|
|
Either require GCC 8 or drop powerpc, up to you. |
|
There's an ICE on aarch64 with gcc 8, move to the next (9) |
9648cff to
ce99359
Compare
|
Sounds like this package is a magnet for GCC ICEs. Good luck |
|
Also, ask yourself how much you care about supporting powerpc vs aarch64 |
|
powerpc vs aarch64 ... vs older Linux distributions 😊 Do we have an overview of which releases of the common/main linux distributions one looses when bumping GCC versions...? |
https://repology.org/project/gcc/versions but I don't see how this is relevant at all. |
|
When working with build recipes, I know that one should use the minimal GCC version, to link against a sufficiently early glibc, but it is (for me) a bit opaque which Linux distributions I loose when I bump, e.g., GCC v7 to v8. |
Glibc and GCC are completely orthogonal: for a given architecture, we use the same glibc for all versions of GCC, so there's no connection between the two, Glibc version only depends on the architecture, and that's what's reported in |
There's no connection for anyone who uses julia's default build system, e.g. when using the official binaries. |
|
Ah OK - thanks for clarifying :-) |
|
Hmm... importing/registration of Faiss_jll failed due to MKL... @giordano Would it be better to just link with libblastrampoline? (and also circumvent OpenBLAS/PowerPC-issues...?) Similar to MKL issues with Torch: JuliaRegistries/General#68946 (comment) [ Info: Attempting to `import` package
Precompiling project...
291.4 ms ✓ Unicode
432.2 ms ✓ Zlib_jll
500.4 ms ✓ CompilerSupportLibraries_jll
600.4 ms ✓ Preferences
779.4 ms ✓ LazyArtifacts
396.2 ms ✓ JLLWrappers
741.9 ms ✓ LLVMOpenMP_jll
774.1 ms ✓ OpenBLAS32_jll
782.9 ms ✓ oneTBB_jll
893.1 ms ✓ LAPACK_jll
1221.5 ms ✓ IntelOpenMP_jll
3260.8 ms ✓ MKL_jll
12226.8 ms ✓ Faiss_jll
13 dependencies successfully precompiled in 18 seconds. 21 already precompiled.
2 dependencies had output during precompilation:
┌ Faiss_jll
│ Downloading artifact: MKL
└
┌ MKL_jll
│ Downloading artifact: IntelOpenMP
└
ERROR: InitError: could not load library "/tmp/jl_OhsE09/artifacts/3b754606efe15fe32e87992916170a076ef1db27/lib/libfaiss.so"
libmkl_intel_lp64.so.2: cannot open shared object file: No such file or directory |
|
I think I already answered in the link you shared, didn't I? |
Due to issue with linking with MKL: JuliaPackaging#8572 (comment) Also, removes the need to build with a newer GCC (than v7) wrt. OpenBLAS on PowerPC64LE.
Due to issue with linking with MKL: JuliaPackaging#8572 (comment) Also, removes the need to build with a newer GCC (than v7) wrt. OpenBLAS on PowerPC64LE.
* [Faiss] Replaced MKL with libblastrampoline Due to issue with linking with MKL: #8572 (comment) Also, removes the need to build with a newer GCC (than v7) wrt. OpenBLAS on PowerPC64LE. * Reduced lbt configure * Reduced lbt configure * Enabled Windows builds to find lbt * Enabled lbt for armv6l * Configured lbt via CMake 3.30 BLA_VENDOR variable * Removed yggy comment
No description provided.