Skip to content
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

[libsingular_julia] update to v0.21 #4285

Merged
merged 3 commits into from
Jan 31, 2022
Merged

Conversation

tthsqe12
Copy link
Contributor

No description provided.

@giordano
Copy link
Member

Sigh, also this one is blocked by JuliaLang/Pkg.jl#2942.

@tthsqe12
Copy link
Contributor Author

let's try again

@tthsqe12 tthsqe12 closed this Jan 20, 2022
@tthsqe12 tthsqe12 reopened this Jan 20, 2022
@giordano
Copy link
Member

Ok, this now works for Julia 1.7+. Maybe drop Julia v1.6? :trollface:

@tthsqe12
Copy link
Contributor Author

I don't think we can do that. @thofma @fingolfin

@thofma
Copy link
Contributor

thofma commented Jan 21, 2022

No, we can't. The offending package he cannot find is
https://github.com/JuliaRegistries/General/blob/ae85bd68a65412602ab29733c890954e9944b744/L/LibOSXUnwind_jll/Package.toml
Why would this be related?

@giordano
Copy link
Member

It's explained in JuliaLang/Pkg.jl#2942 (comment). LibOSXUnwind_jll used to be a stdlib and a dependency of libjulia_jll, but now that's no longer a stdlib (I didn't know we were allowed to remove stdlibs, and indeed that wreaks havoc)

@thofma
Copy link
Contributor

thofma commented Jan 21, 2022

Thanks, I (thankfully?) missed the recent fun. Is this just a problem during the build here and if so, can we just build and deploy using 1.6?

@giordano
Copy link
Member

We moved to Julia v1.7 in #4261, I'd rather not go back to Julia v1.6. We should look into a workaround for the problem in Pkg.

@thofma
Copy link
Contributor

thofma commented Jan 21, 2022

OK, thanks for looking into this. I guess we will have to wait.

@fingolfin
Copy link
Member

Urgh. This is bad.

I mean in theory, we could go back to building everything twice, this time once for 1.6 and once for >= 1.7. But we worked so hard to avoid just that! And it seems so silly...

The annoying part is that LibOSXUnwind_jll is only a dependency because libunwind.h is included in julia_internal.h and again in julia_threads.h. This wouldn't matter for users of libjulia_jll though if julia.h didn't include those headers...

Actually I think the include in julia_threads.h could simply be removed (no unw_* / UNW_ symbols are used in it). And julia_internal.h is not even included from julia.h (and arguably that's what project using libjulia_jll care about).

@giordano
Copy link
Member

For the record, I was hoping we could work around the issue with

    BuildDependency(get_addable_spec("LibOSXUnwind_jll", v"0.0.6+1");
                    platforms=filter(p -> p["julia_version"]=="1.6.0", platforms)),

but in this way I get a different error

ERROR: LoadError: IOError: mkdir("/usr/share/julia/stdlib/v1.7/LibOSXUnwind_jll"; mode=0o777): permission denied (EACCES)
Stacktrace:
  [1] uv_error
    @ ./libuv.jl:97 [inlined]
  [2] mkdir(path::String; mode::UInt16)
    @ Base.Filesystem ./file.jl:183
  [3] mkpath(path::String; mode::UInt16)
    @ Base.Filesystem ./file.jl:234
  [4] mkpath
    @ ./file.jl:229 [inlined]
  [5] (::Pkg.Types.var"#42#43"{Pkg.Types.Context, Pkg.Types.PackageSpec, String})(repo::GitRepo)
    @ Pkg.Types /usr/share/julia/stdlib/v1.7/Pkg/src/Types.jl:732
  [6] with(f::Pkg.Types.var"#42#43"{Pkg.Types.Context, Pkg.Types.PackageSpec, String}, obj::GitRepo)
    @ LibGit2 /usr/share/julia/stdlib/v1.7/LibGit2/src/types.jl:1150
  [7] handle_repo_add!(ctx::Pkg.Types.Context, pkg::Pkg.Types.PackageSpec)
    @ Pkg.Types /usr/share/julia/stdlib/v1.7/Pkg/src/Types.jl:676
  [8] handle_repos_add!(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec})
    @ Pkg.Types /usr/share/julia/stdlib/v1.7/Pkg/src/Types.jl:743
  [9] add(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; preserve::Pkg.Types.PreserveLevel, platform::Platform, kwargs::Base.Pairs{Symbol, Base.TTY, Tuple{Symbol}, NamedTuple{(:io,), Tuple{Base.TTY}}})
    @ Pkg.API /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:248
 [10] (::BinaryBuilderBase.var"#88#94"{Bool, Prefix, Vector{Pkg.Types.PackageSpec}, Platform, Vector{String}, Vector{String}})()
    @ BinaryBuilderBase ~/.julia/dev/BinaryBuilderBase/src/Prefix.jl:572
 [11] activate(f::BinaryBuilderBase.var"#88#94"{Bool, Prefix, Vector{Pkg.Types.PackageSpec}, Platform, Vector{String}, Vector{String}}, new_project::String)
    @ Pkg.API /usr/share/julia/stdlib/v1.7/Pkg/src/API.jl:1599
 [12] setup_dependencies(prefix::Prefix, dependencies::Vector{Pkg.Types.PackageSpec}, platform::Platform; verbose::Bool)
    @ BinaryBuilderBase ~/.julia/dev/BinaryBuilderBase/src/Prefix.jl:565
 [13] (::BinaryBuilder.var"#setup_deps#27")(f::typeof(BinaryBuilderBase.is_target_dependency), prefix::Prefix, dependencies::Vector{BinaryBuilderBase.AbstractDependency}, platform::Platform, verbose::Bool)
    @ BinaryBuilder ~/.julia/dev/BinaryBuilder/src/AutoBuild.jl:754
 [14] autobuild(dir::AbstractString, src_name::AbstractString, src_version::VersionNumber, sources::Vector{<:BinaryBuilderBase.AbstractSource}, script::AbstractString, platforms::Vector, products::Vector{<:Product}, dependencies::Vector{<:BinaryBuilderBase.AbstractDependency}; verbose::Bool, debug::Bool, skip_audit::Bool, ignore_audit_errors::Bool, autofix::Bool, code_dir::Union{Nothing, String}, require_license::Bool, kwargs::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})
    @ BinaryBuilder ~/.julia/dev/BinaryBuilder/src/AutoBuild.jl:757
 [15] build_tarballs(ARGS::Any, src_name::Any, src_version::Any, sources::Any, script::Any, platforms::Any, products::Any, dependencies::Any; julia_compat::String, kwargs::Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})
    @ BinaryBuilder ~/.julia/dev/BinaryBuilder/src/AutoBuild.jl:321
 [16] top-level scope
    @ ~/repo/Yggdrasil/L/libsingular_julia/build_tarballs.jl:58
in expression starting at /home/mose/repo/Yggdrasil/L/libsingular_julia/build_tarballs.jl:58

@giordano
Copy link
Member

I can confirm the hack above works nicely when using Julia master. We may have to upgrade the julia version we use in Yggdrasil.

@thofma
Copy link
Contributor

thofma commented Jan 28, 2022

@giordano Do you think there is a solution in sight?

@giordano
Copy link
Member

Trying to find a working solution in JuliaPackaging/BinaryBuilderBase.jl#212, without much success so far though

@fingolfin
Copy link
Member

I hope we can address this by adjusting libjulia_jll to not depend on LibOSXUnwind_jll anymore, see the WIP in #4320 .

@giordano
Copy link
Member

That'd also be great, yes

@fingolfin
Copy link
Member

Until we have a "proper" solution, perhaps the same hack workaround as used in #4264 can be used to make this JLL build again. Until we have a proper fix -- this way, at least we can go on with work on Singular etc.

@thofma
Copy link
Contributor

thofma commented Jan 30, 2022

I would be in favour of this.

Copy link
Contributor

@thofma thofma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Maybe @fingolfin could also have a quick glance.

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@giordano giordano merged commit 01620e1 into JuliaPackaging:master Jan 31, 2022
simeonschaub pushed a commit to simeonschaub/Yggdrasil that referenced this pull request Feb 23, 2022
* [libsingular_julia] update to v0.21

* Update build_tarballs.jl

* add some workarounds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants