-
Notifications
You must be signed in to change notification settings - Fork 554
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
[HSL] Compile v1.0.0 #6549
[HSL] Compile v1.0.0 #6549
Conversation
I am not sure why a |
@vchuravy The shared library that we precompile requires some dependencies (METIS, BLAS/LAPACK, MPI). By using a |
Your non JLL package can also depend on these dependencies. JLL packages are not special in that way. |
Ok so an alternative solution is to add The drawbacks that I have in mind are:
@odow Can you give your point of view too? |
I think @vchuravy's point was that we don't need this to be a jll with a C dependency. The actual We register an |
I don't understand this. Can you explain why it's needed? |
I thought that Valentin wanted that we give a path to the precompiled shared library |
Ok, I misunderstood the point of @vchuravy. For the current use of GALAHAD doesn't provide an option to load a such that we can compile them here in the shared library of the dummy |
The HSL team is happy to have this dummy JuliaHSL v1.0.0 package. This can then be bumped to v2.0.0 for GALAHAD in future once its Julia interfaces are ready. |
@amontoison Please merge when you feel this is ready. |
@ViralBShah Can you merge it? |
@amontoison I have invited you to have Yggdrasil commit access. |
* master: (38 commits) Bump LLVM to 14.0.6-3 (JuliaPackaging#6589) [llama_cpp] Bump version (JuliaPackaging#6588) [GMT] Let libcurl_jll compat have 7.7s and 8.0.1 (JuliaPackaging#6586) Make autotools more relocatable (JuliaPackaging#6585) [Libtool] Clean up, add more executable products (JuliaPackaging#6581) Bump MParT_jll to 2.0.2 (JuliaPackaging#6584) [automake] Add Automake `v1.16` (JuliaPackaging#6583) [autoconf] Add `autoconf` `v2.71` (JuliaPackaging#6582) [Bison] ensure the package does not hardcode paths (JuliaPackaging#6580) [gawk] Add v5.2.1 (JuliaPackaging#6579) New Recipe: Kira v2.3.0 (JuliaPackaging#6485) Regenerate PTSCOTCH_jll with a compat entry for SCOTCH_jll (JuliaPackaging#6575) [file] Add GNU file `v5.44` (JuliaPackaging#6573) [HSL] Compile v1.0.0 (JuliaPackaging#6549) Regenerate MUMPS_jll with a compat entry for SCOTCH_jll (JuliaPackaging#6576) Regenerate MMG_jll with a compat entry for SCOTCH_jll (JuliaPackaging#6571) Regenerate neper_jll with a compat entry for SCOTCH_jll (JuliaPackaging#6572) [Singular] update to 4.3.2-0 + depth pathches (JuliaPackaging#6577) Regenerate qr_mumps_jll with a compat entry for SCOTCH_jll (JuliaPackaging#6574) [patch] Add Patch `v2.7.6` (JuliaPackaging#6570) ...
Thanks @ViralBShah and @giordano for the invitations! I found a way to have an unique function __init__()
JLLWrappers.@generate_init_header(CompilerSupportLibraries_jll, MPICH_jll, METIS_jll, libblastrampoline_jll)
JLLWrappers.@init_library_product(
libhsl,
"lib/aarch64-apple-darwin-libgfortran5/libhsl.dylib",
RTLD_LAZY | RTLD_DEEPBIND,
)
JLLWrappers.@generate_init_footer()
end # __init__() function __init__()
JLLWrappers.@generate_init_header(CompilerSupportLibraries_jll, MicrosoftMPI_jll, METIS_jll, libblastrampoline_jll)
JLLWrappers.@init_library_product(
libhsl,
"bin\\x86_64-w64-mingw32-libgfortran5\\libhsl.dll",
RTLD_LAZY | RTLD_DEEPBIND,
)
JLLWrappers.@generate_init_footer()
end # __init__() function __init__()
JLLWrappers.@generate_init_header(CompilerSupportLibraries_jll, MPICH_jll, METIS_jll, libblastrampoline_jll)
JLLWrappers.@init_library_product(
libhsl,
"lib/x86_64-linux-gnu-libgfortran5/libhsl.so",
RTLD_LAZY | RTLD_DEEPBIND,
)
JLLWrappers.@generate_init_footer()
end # __init__() it works perfectly except for Apple platforms, julia> using HSL_jll
ERROR: InitError: could not load library "/Users/alexis/Downloads/HSL_jll/override/lib/x86_64-apple-darwin-libgfortran4/libhsl.dylib"
dlopen(/Users/alexis/Downloads/HSL_jll/override/lib/x86_64-apple-darwin-libgfortran4/libhsl.dylib, 1): no suitable image found. Did find:
/Users/alexis/Downloads/HSL_jll/override/lib/x86_64-apple-darwin-libgfortran4/libhsl.dylib: code signature in (/Users/alexis/Downloads/HSL_jll/override/lib/x86_64-apple-darwin-libgfortran4/libhsl.dylib) not valid for use in process using Library Validation: library load disallowed by system policy I generated the tarballs with BinaryBuilder.jl on my Linux (Ubuntu 22.04 -- x86_64-linux-gnu-libgfortran5). |
No, we sign on Linux, like the rest of the building pipeline. But I'm not sure this answers your question. |
It's a good news that you sign the tarballs on Linux. We use the command julia --color=yes build_tarballs.jl aarch64-apple-darwin-libgfortran5,aarch64-linux-gnu-libgfortran3,aarch64-linux-gnu-libgfortran4,aarch64-linux-gnu-libgfortran5,aarch64-linux-musl-libgfortran3,aarch64-linux-musl-libgfortran4,aarch64-linux-musl-libgfortran5,powerpc64le-linux-gnu-libgfortran3,powerpc64le-linux-gnu-libgfortran4,powerpc64le-linux-gnu-libgfortran5,x86_64-apple-darwin-libgfortran3,x86_64-apple-darwin-libgfortran4,x86_64-apple-darwin-libgfortran5,x86_64-linux-gnu-libgfortran3,x86_64-linux-gnu-libgfortran4,x86_64-linux-gnu-libgfortran5,x86_64-linux-musl-libgfortran3,x86_64-linux-musl-libgfortran4,x86_64-linux-musl-libgfortran5,x86_64-unknown-freebsd-libgfortran3,x86_64-unknown-freebsd-libgfortran4,x86_64-unknown-freebsd-libgfortran5,x86_64-w64-mingw32-libgfortran3,x86_64-w64-mingw32-libgfortran4,x86_64-w64-mingw32-libgfortran5 --debug --verbose --deploy="local" to generate the tarballs for all 64-bits platforms. |
@giordano @staticfloat An alternative solution is to ask the users to resign the shared libraries.
or
|
Honestly I don't understand the problem. The library is already signed during audit as far as I can tell: https://buildkite.com/julialang/yggdrasil/builds/2175#01876299-9fbf-439c-8655-972f62f972e1/638-770 |
@dpo @ViralBShah @staticfloat
With the HSL team, we developed a
JuliaHSL
package that contains all the HSL packages together.Because the package
JuliaHSL
requires an academic license, we can't precompile it here with Yggdrasil.To ease the use of it in the Julia ecosystem, we compile a dummy version here such that we can add it as a dependency of any Julia package.
The dummy version only has one C routine and the users will be able to call it to check if they have the dummy version or not and potentially call other routines.
The users will be able to download the
JuliaHSL
package (source code) with the "real"HSL_jll.jl
Julia package (for Julia >= 1.9) from https://licences.stfc.ac.uk/.It requires Julia v1.9 because we want to use LBT on all platforms.
The real
HSL_jll
has the same products than the dummyHSL_jll.jl
package generated here. The main difference is that we have anoverride
folder with the content of the "real" tarballs precompiled with BinaryBuilder.jl at the Rutherford Appleton Laboratory (RAL).Thus, the RAL will provide these archives:
The user will choose the archive based on the result of
Base.BinaryPlatforms.host_triplet()
and install it with just adev .
.Comments:
Artifacts.toml
even if we have anoverride
folder. Julia will not use it but it returns an error if it can't download an archive;hsl_ma57
solver is used for sparse\
in MATLAB.