Ipopt.jl: LibIpopt issues on Mac about ipopt.jl HOT 14 CLOSED

What happens if you run Pkg.build("Ipopt") ?

from ipopt.jl.

Seems to go just fine:

Pkg.build("Ipopt")
INFO: Building Homebrew
HEAD is now at f52c5f1 Update test dependencies
HEAD is now at 885ba65 Merge pull request #40 from staticfloat/staging
INFO: Building Ipopt

WARNING: deprecated syntax "[a=>b, ...]" at /Users/arora/.julia/v0.4/Ipopt/deps/build.jl:72.
Use "Dict(a=>b, ...)" instead.

from ipopt.jl.

When I run the test script outside REPL. I got:

dyld: lazy symbol binding failed: Symbol not found: _MPI_Init
Referenced from: /usr/local/lib/libipopt.dylib
Expected in: flat namespace

dyld: Symbol not found: _MPI_Init
Referenced from: /usr/local/lib/libipopt.dylib
Expected in: flat namespace

Trace/BPT trap: 5

This looks like a flat-namespace issue on Mac OSX. Maybe I need to recompile the binary and then use inside Julia ?

from ipopt.jl.

What does the file /Users/arora/.julia/v0.4/Ipopt/deps/deps.jl say? It looks like it's picking up a previously compiled version of ipopt which is trying to use the MPI version of Mumps (which isn't going to work well). You could maybe do brew unlink ipopt, re-run Pkg.build("Ipopt") then hopefully it would download the for-use-with-Julia version of Ipopt instead of the homebrew-science one.

from ipopt.jl.

This is what the deps.jl file has:

macro checked_lib(libname, path)
((VERSION >= v"0.4.0-dev+3844" ? Base.Libdl.dlopen_e : dlopen_e)(path) == C_NULL) && error("Unable to load \n\n$libname ($path)\n\nPlease re-run Pkg.build(package), and restart Julia.")
quote const $(esc(libname)) = $path end
end

@checked_lib libipopt "/usr/local/lib/libipopt.dylib"

I will try the brew unlike tomm. morning and get back to you. But I did not install Ipopt using brew before (just did a make on the source ) and I just installed the brew package manager recently.

thanks a lot !

from ipopt.jl.

Okay, if your locally compiled version is not from homebrew then the cleanest way of removing it would be finding the original source build and running make uninstall from there. I think there is a stub standin for MPI in the sequential build of mumps but I'm not sure what's going wrong here.

You might also get away with temporarily renaming /usr/local/lib/libipopt.dylib to something else, to force Pkg.build("Ipopt") to download its own version.

from ipopt.jl.

You are correct, I am linking to the old version of libipopt.
Looks like MPI was the culprit like you pointed out. But I was still getting errors after renaming the default libipopt library so then I commented out the Homebrew specific lines

@osx_only begin
    using Homebrew
   provides(Homebrew.HB, "ipopt", libipopt, os = :Darwin)
end

in Build.jl inside Ipopt directory ( /Users/arora/.julia/v0.4/Ipopt) and again ran Pkg.build("Ipopt"). Ipopt was complied from source.

Everything worked then including the examples! thanks for all the help 👍

Maybe there should be a way to bypass Homebrew if it is not working and just compile from the source ?

from ipopt.jl.

What was the problem when you didn't have the homebrew provider commented out? You more or less found the "way to bypass Homebrew" here.

from ipopt.jl.

It was always relinking with Homebrew (when I unlinked it). I think the issue mite be that I had a previous compiled version of Ipopt installed and that was confusing Homebrew. I am not sure though.

Do you want me to close this ?

from ipopt.jl.

To clarify a little, when you do Pkg.build("Ipopt"), or for other packages that use https://github.com/JuliaLang/Homebrew.jl to manage binary dependencies on OS X, it's actually using a private sandboxed version of Homebrew that lives inside Pkg.dir("Homebrew"), and should be independent of your global system Homebrew installation. So the linking there won't be to a globally visible system-wide location like /usr/local, it will be inside /Users/arora/.julia/v0.4/Homebrew/usr or something similar.

Your system-wide homebrew was actually not the problem here at all, rather it was that when a pre-existing copy of the ipopt library was found, BinDeps decided to use that instead of downloading a new binary.

from ipopt.jl.

Ahh, I see, I wasn't aware of that. Thanks for the clarification. I do see that Ipopt directory in the Julia specific Homebrew. Not sure why BinDeps decided to use the /usr/local/lib copy of the library.

Will close issue this now. Thank you again.

from ipopt.jl.

Not sure why BinDeps decided to use the /usr/local/lib copy of the library.

That's by design (I think). If it finds a library in the default search path that has the same name as what you're looking for, and it passes some validation tests (the default test is "can this library be dlopened", but a more comprehensive custom validation test might have been able to catch the issue with MPI that you ran into), then it assumes you wanted to use that version. Some people will want to use a custom-compiled version of the Ipopt library with the Julia package, and I don't think we should rule out that use case, but it has seemed to lead to problems for multiple users now.

from ipopt.jl.

I see, is it possible to tell BindDeps via the Pkg.add command whether to use a custom build Ipopt or not? I am new to Julia so am not aware of some of it's features yet.

from ipopt.jl.

Not that I know of. Neither Pkg.add or Pkg.build have any optional arguments, except for a version number in the case of Pkg.add.

from ipopt.jl.