A recommendation for code revision

[Yue-Wang-qvp]

I suggest to revise the build.jl like this
"
const ALIASES = [
"gurobi100",
"gurobi95",
"gurobi91",
"gurobi90"
]

paths_to_try = []
"

The reason is that the original piece of code "paths_to_try = copy(ALIASES)" will result in the library handle variable like "libgurobi = gurobi100". Such a handle variable does not include the absolute path and makes a compiled package with "Gurobi.jl" throw error of "ErrorException("could not load library "gurobi 100"".

[odow]

and makes a compiled package with "Gurobi.jl"

What do you mean by "compiled"?

We need the code as-is, because many users have Gurobi on their PATH and haven't set the GUROBI_HOME environment variable.

When building Gurobi, we'll only write out the library path as gurobi100 if it exists on the PATH, so if you're running into issues after this, then you've probably removed Gurobi from PATH. Just re-add it.

[Yue-Wang-qvp]

I indeed have GUROBI_HOME environment variable and also the directory of 'gurobi100' in the Path, so I am able to successfully call for gurobi100.dll in my package or any other Julia script .jl. However, after I use PackageCompiler.create_library() to create a standalone APP from my package, running the APP will throw an error containing the prompt of ErrorException("could not load library "gurobi 100". I am not familiar with the mechanism of PackageCompiler.create_library(), and have to modify the code of Gurobi.jl to be paths_to_try = [] after many attempts. Such a modification succeed in directing the APP to find the gurobi100.dll.

[odow]

Once you have the app, it should still work if Gurobi is on your PATH. Did you run the binary from a difference computer where Gurobi wasn't on the PATH?

@joaquimg is the person with experience doing this and may have some suggestions.

[Yue-Wang-qvp]

The strange question is that the compiled APP can even not succeed on my own computer, and the slight modification of "paths_to_try = []" can solve it perfectly.

[odow]

But presumably if you set paths_to_try = [] it will end up hard-coding the path to your libgurobi, and then if you move computers that won't work either?

[Yue-Wang-qvp]

No, the app can be executed successfully in another computer which even has different version of Gurobi installed, provided that paths_to_try = [] was used when compiling the app

[odow]

Is it a linux machine? If so, when paths_to_try=[], your first machine is not using the local version of Gurobi, and when you move it to the new machine, it also downloads the artifact:

Gurobi.jl/src/Gurobi.jl

Lines 16 to 23 in 7145c28

	if isdefined(@__MODULE__, :libgurobi)
	# deps.jl must define a local installation.
	elseif Sys.islinux()
	# Let's use the artifact instead.
	const libgurobi = joinpath(
	LazyArtifacts.artifact"gurobilinux64",
	"gurobi1000/linux64/lib/libgurobi100.so",
	)

If you leave paths_to_try unmodified, then your first machine is finding libgurobi on the system path, and then it can't find Gurobi on the new machine. If the binary doesn't work on the original machine either, then the binary must be mucking with the PATH, but I don't know why or the details of how to fix.

If you want to run on linux only, then I'd suggest removing Gurobi from the path before compiling.

[odow]

Any updates on this?

[Yue-Wang-qvp]

I am runing windows

[odow]

See https://julialang.github.io/PackageCompiler.jl/dev/devdocs/relocatable_part_3.html#Relocatability-of-Julia-packages

PackageCompiler currently does not work well with packages which require hard-code paths for external binaries.

The best work-around is probably to have gurobi100 in your PATH of the build machine so that it gets written to deps.jl, and then set a similar PATH in the deployment machine.

[odow]

The new version of Gurobi.jl uses binaries provided by Gurobi_jll, so it should work by default on any machine that has a valid Gurobi license. You do not need to manually install or specify the path in the build step.