Yggdrasil icon indicating copy to clipboard operation
Yggdrasil copied to clipboard

SLICOT 5.8.1, Julia 1.8 compat

Open mkitti opened this issue 3 years ago • 5 comments

Someone should do something like #4770 (for lack of better options at the moment)

Originally posted by @giordano in https://github.com/JuliaPackaging/Yggdrasil/issues/4969#issuecomment-1146836975

I'm "someone".

https://discourse.julialang.org/t/too-many-julia-versions/84538/15?u=mkitti

  1. Do we need a version bump to SLICOT 5.8.1 to do this?
  2. @andreasvarga can we coordinate a SLICOT 5.8.1 release?

cc: @RalphAS

mkitti avatar Aug 01 '22 12:08 mkitti

OK. So once again my reply to your proposal.

The best for SLICOT integration would be of course to have compatibility starting with the LTS version, as well as with the current and future versions. I appreciate very much your help in this respect. If necessary, I could produce a version bump to 5.8.1 for SLICOT itself, just to keep the right correspondence between the versions. Is this OK for you?

andreasvarga avatar Aug 01 '22 13:08 andreasvarga

I'm not sure if compatibility with Julia 1.6 is possible at this point since I think the version mechanism depends on new functionality, but I would be happy to corrected.

mkitti avatar Aug 01 '22 14:08 mkitti

This was only a wishful thinking of me (not important for further developments).

andreasvarga avatar Aug 01 '22 14:08 andreasvarga

Thanks for picking this up. You might have a new record for the number of tarballs.

Julia v1.6 would need a different approach because libblastrampoline was only partly integrated. It could be difficult to keep the versioning in order with the two builds in parallel.

RalphAS avatar Aug 01 '22 14:08 RalphAS

Now I've remembered why I didn't do this earlier: the builds should really be sorted by version of libblastrampoline rather than version of Julia, and I didn't figure out a simple way to do that.

RalphAS avatar Aug 02 '22 02:08 RalphAS

Sorry for my ignorance, but what follows now? In the meantime, I have troubles even registering under Julia v1.7 (see #68456).

andreasvarga avatar Sep 17 '22 14:09 andreasvarga

This is failing to build. If someone could debug this, that'd be much appreciated.

giordano avatar Sep 18 '22 12:09 giordano

The linker is failing to find libblastrampoline. It seems to be looking in /workspace/destdir/lib which it gets as the shell variable ${libdir}. Has there been a relevant recent change in BinaryBuilder?

RalphAS avatar Sep 18 '22 14:09 RalphAS

No

giordano avatar Sep 18 '22 14:09 giordano

It is only failing to find libblastrampoline on certain platform triples.

mkitti avatar Sep 18 '22 15:09 mkitti

The Julia 1.7 builds succeed. Thr Julia 1.8 and Julia 1.9 builds fail.

mkitti avatar Sep 18 '22 15:09 mkitti

For Julia 1.7 v3.0.4 of blastrampoline is used, which is OK. For Julia 1.8 and 1.9, version v5.1.0 is used and not the last available version v5.1.1. I wonder if this is a problem. Moreover, for 1.8 and 1.9, version v3.0.4 is also mentioned in the script. I can not figure out what effect this may have.

andreasvarga avatar Sep 18 '22 15:09 andreasvarga

OK, I will try that.

Also do you have any plans to release a SLICOT 5.8.1. This will be released as 5.8.1 and it would be nice to keep the versions synchronized.

mkitti avatar Sep 18 '22 15:09 mkitti

I observed that the last call to generate the binaries contains a dependency to julia 1.7. Is this a lower limit on the version or it must be also adapted to various julia versions ?

andreasvarga avatar Sep 18 '22 16:09 andreasvarga

I propose to keep the version of SLICOT as it is now.

andreasvarga avatar Sep 18 '22 16:09 andreasvarga

At the moment, I believe we still need to bump the version number here in this packaging for Julia 1.7 compat at least.

mkitti avatar Sep 18 '22 16:09 mkitti

I observed that the last call to generate the binaries contains a dependency to julia 1.7. Is this a lower limit on the version or it must be also adapted to various julia versions ?

julia_compat=v"1.7" indicates compatibility with Julia versions [1.7, 2.0) per https://pkgdocs.julialang.org/v1/compatibility/#Version-specifier-format

mkitti avatar Sep 18 '22 16:09 mkitti

I'm not entirely sure we need to bump the version number: that's necessary when changing the generated project file (new dependencies, or julia compat), which isn't the case here? There was a libblastrampoline compat, but that was kinda redundant since libblastrampoline is a stdlib, bound to julia anyway.

giordano avatar Sep 18 '22 16:09 giordano

b9a67f0 looks good for 1.8 compat.

  • Expanding again to 1.7 and 1.9
  • Shoved this package version back to 5.8.0

Let's see if this still works.

mkitti avatar Sep 18 '22 16:09 mkitti

CI is green. Version is 5.8.0. Let's go?

mkitti avatar Sep 18 '22 17:09 mkitti

Congratulations and many thanks!

andreasvarga avatar Sep 18 '22 17:09 andreasvarga

Don't celebrate too soon; the package doesn't seem to be consistent yet: https://github.com/JuliaRegistries/General/pull/68512 says

ERROR: Unsatisfiable requirements detected for package libblastrampoline_jll [8e850b90]: libblastrampoline_jll [8e850b90] log: ├─possible versions are: 5.1.1 or uninstalled └─found to have no compatible versions left with SLICOT_jll [545525a2] └─SLICOT_jll [545525a2] log: ├─possible versions are: 5.7.0-5.8.0 or uninstalled └─restricted to versions 5.8.0 by an explicit requirement, leaving only versions 5.8.0

Previously, @giordano fixed a similar problem by adding a compat bound for LBT to Project.toml, but that won't work when the compat depends on the Julia version. Maybe drop Julia v1.7 and set the LBT bound to 5.0?

RalphAS avatar Sep 19 '22 02:09 RalphAS

Actually, I'm pretty sure the current issue is due to the previous compat bound for libblastrampoline_jll.

https://github.com/JuliaRegistries/General/pull/68512/files does not attempt to change Compat.toml. So the existing Compat.toml still applies: https://github.com/JuliaRegistries/General/blob/master/S/SLICOT_jll/Compat.toml

mkitti avatar Sep 19 '22 06:09 mkitti

This is a similar problem for which I opened an issue when trying to register a new version of PeriodicSystems. This issue has been closed, with the conclusion that

AutoMerge always runs with the latest stable Julia, which is currently Julia 1.8. If your package does not support Julia 1.8, it will fail AutoMerge, and you will need to request a manual merge.

However, in our case we are at a lower level (registering the library itself), so I assume if we manage to solve this issue we will solve also #68456 .

Just a remark: The PR example used as template for producing SLICOT_jll was for a package/library Pfapack, which apparently was never registered in Julia (only a Python version exists)!

andreasvarga avatar Sep 19 '22 08:09 andreasvarga

https://github.com/JuliaRegistries/General/pull/68512 has been merged.

Now we need to turn our attention to PeriodicSystems we have compat issues over there now.

mkitti avatar Sep 19 '22 16:09 mkitti

https://juliahub.com/ui/Packages/Pfapack_jll/HOmkl/0.1.0+1?page=1 Pfapack_jll is registered by the way.

mkitti avatar Sep 19 '22 16:09 mkitti

I formulated an issue regarding the failure of PeriodicSystems release 0.4.2 on Windows with Julia 1.8 (with Julia 1.7 it works, as well as on Linux). I can easily reproduce the failure locally by using any call involving the wrappers I implemented for several SLICOT routines. Each call crashes Julia (so I can not see the actual error), but from the CI.log, the error is basically

Exception: EXCEPTION_ACCESS_VIOLATION at 0x0 -- unknown function (ip: 0000000000000000)
in expression starting at D:\a\PeriodicSystems.jl\PeriodicSystems.jl\test\test_pschur.jl:15
unknown function (ip: 0000000000000000)
Allocations: 107208134 (Pool: 107190352; Big: 17782); GC: 43

I guess, something is wrong with the generated SLICOT_jll for Windows under Julia 1.8.

Very gratefull for any idea how to fix this issue.

andreasvarga avatar Sep 20 '22 11:09 andreasvarga