Fix 1.9 - #757
Conversation
8b23afb to
aff3d51
Compare
Codecov Report
@@ Coverage Diff @@
## master #757 +/- ##
==========================================
- Coverage 83.33% 81.06% -2.28%
==========================================
Files 3 3
Lines 600 660 +60
==========================================
+ Hits 500 535 +35
- Misses 100 125 +25
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
The remaining 1.9+ failure is #755 |
IanButterworth
changed the title
|
Locally on julia master I get |
Does your local Julia master include JuliaLang/julia#48131? |
Yeah it does. I'm on JuliaLang/julia#48168 |
|
Does this mean that JuliaLang/julia#48131 didn't completely fix JuliaLang/julia#48111? |
|
I don't know. It didn't happen all the time. Tests locally, where:
Although I never saw this error but I did see a lot of which is checked after the flags check, so flag check appears to be passing locally. I'm quite confused here.. |
|
If it's informative I dumped cc. @vchuravy |
|
What are you setting JULIA_CPU_TARGET to? |
|
During tests it appears to be the default PackageCompiler.jl/src/PackageCompiler.jl Line 33 in 28cb6cb |
|
pkgimages are somehow disabled in |
|
Ohhh.. |
5fd6bc7 to
22c4ccb
Compare
|
Ok, with coverage disabled (and thus pkgimages enabled and with -O3 set during precompilation) this is now hitting the issue I see locally |
984cdcd to
b02c438
Compare
I am not sure I understand the issue here. Is the issue that we have a time-out since we are rejecting every cache file? What is happening is that we create a pkgimage cachefile for a particular target (either native or multiversioning) and then have started a Julia session that uses a different target. |
|
Maybe the right answer here is to run with Also I think you need to set the environment flag not the command line flag since Julia will complain. |
Yeah. Especially given the sysimage will be built with -O3 and most people's existing pkgimage caches will be -O2. |
|
If there is no chance to reuse the already precompiled files that a user has from an earlier |
|
I mean PackageCompiler will not re-use that information at all. It would be a big rewrite to have PackageCompiler turn into a linker of package images. |
|
This is just for package load times. When you load a package into the process that outputs the sysimage, it will use a precompile file if such a file exist to speed up loading. |
|
Note if it doesn't find a usable cache it currently hits the bug where myrand is zero. |
|
Yew, because |
014ef69 to
4ab43b0
Compare
@vchuravy I couldn't find the environment flag (assuming the sysimage step will fail currently because of this) |
|
I'm surprised that 1.9 is passing but nightly is failing |
|
I'm keen to get this fixed because I can't fully test 1.9 in our stack before PackageCompiler works. Given 1.9-nightly works here, I could try this branch, but I'd prefer to use a release. |
|
@vchuravy is the last commit what you meant on slack? And if so, is it backwards compatible, or do I need to only do this on 1.9+? |
|
Should be backwards compatible. Everyone else just ignores it. |
|
hmm, then removing |
|
The handling here feels a bit messy, but as far as I understand it's now correct. So I'll merge and I think a patch release should be made |
4 participants
Closes #755
#755 was due to the sysimage output process being launched with O2 vs the precompiled O3, so the caches were rejected, entering a state where
__init__are not run and the RNG wasn't seeded. i.e. the test correctly caught the issue