You could try to use @giordano suggestion to debug the problem, see in the above thread :
Instead, try this:
]add DependencyWalker Cairo_jll
using Cairo_jll # This will fail, it's ok, but it's needed to load the dependencies
This should hopefully show what modules cannot be found.
Thanks! DependencyWalker helped diagnose the problem: the libssp-0.dll file wasn’t found. Julia 1.8.3 happily finds this in AppData\Local\Programs\Julia-1.8.3\bin\ but for some reason Julia 1.8.4 doesn’t find it in AppData\Local\Programs\Julia-1.8.4\bin\. When I’ve installed Julia on Windows in the past I’ve never ticked the “Add Julia to PATH” box because I prefer not to clutter up my PATH unless it’s necessary but reinstalling with that option has solved the problem.
I’ve no idea why Julia suddenly needs to be on my Windows PATH when it didn’t before. It seems to me that there’s a danger of dll’s getting confused if you have different versions of Julia installed.
I used the windows installer and had the same problem so I don’t think it’s because of juliaup. I don’t fully understand these things but I thought that Windows usually looks for dll’s in the executable directory before searching the PATH so it seems a bit mysterious that the new version doesn’t find them when the old one did.
These type of errors are tricky and the error messages don’t help. The problem is normally related to finding a dependent lib that does not have a certain symbol and the message makes think that it’s the entire shared lib that was not found. Whatever it is, I could not reproduce it, even by having no Julia in PATH.
Agreed, bu note that error messages come from the operating system, that’s why I had to write DependencyWalker.jl: operating systems, basically all of them, don’t tell you which libraries can’t be loaded even though they know it since they just looked for them.
@mkoculak@tt1234567@matnbo or anyone else who can reproduce this problem, without running julia with admin priviliges, do you have the file joinpath(CompilerSupportLibraries_jll.artifact_dir, "bin", "libssp-0.dll") (you need to have the CompilerSupportLibraries_jll package loaded to to do this). If so, can you do
using CompilerSupportLibraries_jll, Libdl
dlopen(joinpath(CompilerSupportLibraries_jll.artifact_dir, "bin", "libssp-0.dll"))
? If so, I have no clue why libssp-0.dll can’t be loaded automatically.
Also, do note that MSIMG32.dll is a Windows system library, if it can’t be found we can do next to nothing about it. Do you have it in your system? I mentioned elsewhere that this library should be part of the Microsoft Graphical Device Interface (GDI), do you have this component in your system?
I uninstalled 1.8.4, made sure the install directory was deleted and reinstalled without the add Julia to PATH checked. The problem returned. libssp-0.dll is definitely in the bin directory but DependencyWalker reports it and MSIMG32.dll as missing. The latter is definitely under C:\Windows\System32 (actually lower case msimg32.dll). I then ran dlopen(...)
The problem is reproducible on my machine. Very strange that it apparently can’t find a dll that’s in the executable’s launch directory but I haven’t much experience of loading dll’s after program start-up.