`7z.exe` and `7z.dll` are not included as dependencies on the bin folder of a compiled package.

[guilhermebodin]

I am distributing some compiled versions of packages and recently a user reported that the module broke because he had no permission to check if there was a 7z library when using the command Sys.which(p7zip_exe) in p7zip_jll. This made me realize that 7z was not being bundled together with other libs since it didn't return after checking if the file existed in the following function.

function init_p7zip_path()
    # Prefer our own bundled p7zip, but if we don't have one, pick it up off of the PATH
    # If this is an in-tree build, `7z` will live in `bin`.  Otherwise, it'll be in `libexec`
    for bundled_p7zip_path in (joinpath(Sys.BINDIR, Base.LIBEXECDIR, p7zip_exe),
                               joinpath(Sys.BINDIR, p7zip_exe))
        if isfile(bundled_p7zip_path)
            global p7zip_path = abspath(bundled_p7zip_path)
            return
        end
    end
    global p7zip_path = something(Sys.which(p7zip_exe), p7zip_exe)
end

It happens that 7z.dll and 7z.exe are not present in the bin folder of julia but are in Base.LIBEXECDIR. Apparently when we compile a package all the files in Base.LIBEXECDIR are not copied together with other dependencies.

Could we add a feature that allows users to add 7z to the libs along with everyother dependency?

[KristofferC]

Yeah, bundling that makes sense.

[guilhermebodin]

I can try to open a PR, I imagine that I would only have to create a new function bundle_libexec_libs_and_executables. Would that be ok?

[sloede]

PackageCompiler v2.1.14 should fix this issue by packaging 7z with library/app bundles. To be precise, it does fully fix it for the cases where, e.g., the MKL artifacts are downloaded only at load time even though they should have been packaged already during PC build time, but that's for another day...