MbedTLS_jll started failing to load

[joa-quim]

I don't know what caused it. Some update maybe (it happened after I tried to install GDAM.jl) but now I have this error that prevents me, for example, to use Pluto

[ Info: Precompiling Pluto [c3e4b0f8-55cb-11ea-2926-15256bba5781]
ERROR: LoadError: InitError: could not load library "C:\Users\joaqu\.julia\artifacts\766d976def66e8367dd690d05cfe422f883d43ba\bin\libmbedtls.dll"
The specified procedure could not be found.
Stacktrace:
  [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
    @ Base.Libc.Libdl .\libdl.jl:114
  [2] dlopen(s::String, flags::UInt32)
    @ Base.Libc.Libdl .\libdl.jl:114
  [3] macro expansion
    @ ~\.julia\packages\JLLWrappers\KuIwt\src\products\library_generators.jl:61 [inlined]
  [4] __init__()
    @ MbedTLS_jll ~\.julia\packages\MbedTLS_jll\bmmwH\src\wrappers\x86_64-w64-mingw32.jl:16

I have experience with this type of errors and so tried to find out but the DependencyWalker was no help this time and I couldn't figure out what is wrong. In the mean time I found that libgcc_s_seh-1.dll is a dependency that is not shipped with the artifact. Right, there is one that comes with the Julia but if Julia/bin is not in the path that dependency wont be found.

I wish the artifacts for Windows were build with Visual Studio and only came with the strict necessary number of files.

EDIT: Seems this the same as #228

[detrin]

The nightly built of Coverage fails therefore as well. I can't run Coverage on windows-latest with Julia nightly in GitHub Actions see https://github.com/detrin/OpenQuantumSystems.jl/runs/1412424632?check_suite_focus=true

[joa-quim]

OK, I gave myself the trouble of building MbedTLS on Windows with Visual Studio. At the end it worked but I had to overcome several shits. First and most, the cmake solution fot the lib doesn't work at all on Windows to build shared libs because no symbols at all are exported. Next, found the -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS option but then several symbols are export whilst on Windows we need to __declspec(dllexport).

As said, at the end I managed to make it work but this is no general solution before the MbedTLS improves the build system to allow true shared libs building on Windows (building the exes now errors because it wants more of those changes).

[detrin]

I am Linux user and I have no experience using cmake under Windows. I am curious, what could cause such an issue.

[joa-quim]

Using cmake is exactly equal on Linux or Windows. The problem is if the internal cmake recipes are not working well, which the case for Windows but not necessarily for Linux. Current issue seems to be due to a missing symbol in one of the shared libs, but I wasn't able to find out which.

[detrin]

So how could I possibly help to resolve this issue?

[joa-quim]

Don't know, I'm just giving the most details I can to the person who builds the MbedTLS_jll artifact, which needs to be fixed.

[visr]

See JuliaLang/julia#38409 (comment). Should hopefully soon be resolved when the linked PR merges.

[lkapelevich]

Looks like this and #228 are fixed now (JuliaLang/julia#38409 (comment))

[joa-quim]

OK, feel free to close. Meanwhile I had solved the problem by building MberTLS myself with Visual Studio.

[greimel]

I don't know if it's related but I cannot precompile Pluto on macOS Catalina on current 1.6-release due to MbedTLS not precompiling.

It's been working on the nightly build that I've been using since now: 1.6.0-DEV.1325 (2020-10-24).

EDIT: I updated to macOS Big Sur last night and now MbedTLS precompiles.

EDIT2: Fails again.