Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build failiure on OSX 10.9 #6

Closed
porterjamesj opened this issue Nov 23, 2013 · 9 comments · Fixed by #145
Closed

build failiure on OSX 10.9 #6

porterjamesj opened this issue Nov 23, 2013 · 9 comments · Fixed by #145

Comments

@porterjamesj
Copy link

When I run Pkg.build("NLopt"), I get the following:

julia> Pkg.build("NLopt")
INFO: Building Homebrew
HEAD is now at 7dbece7 Merge branch 'kegpkg' of github.com:staticfloat/homebrew into kegpkg
HEAD is now at e7a2203 Tab fix didn't work, revert to old behavior
INFO: Building NLopt
=============================================================================================[ ERROR: NLopt ]=============================================================================================

Provider PackageManager failed to satisfy dependency libnlopt
at /Users/james/.julia/NLopt/deps/build.jl:52

==========================================================================================================================================================================================================

=============================================================================================[ BUILD ERRORS ]=============================================================================================

WARNING: NLopt had build errors.

 - packages with build errors remain installed in /Users/james/.julia
 - build a package and all its dependencies with `Pkg.build(pkg)`
 - build a single package by running its `deps/build.jl` script

==========================================================================================================================================================================================================

I'm not familiar enough with BinDeps to know exactly what's going wrong here.

@mlubin
Copy link
Member

mlubin commented Nov 23, 2013

Are you using the julia OS X binary or a build from source?

@staticfloat

@porterjamesj
Copy link
Author

build from source; 0.2.0-rc4

@mlubin
Copy link
Member

mlubin commented Nov 23, 2013

Try running

dlopen("libstdc++",RTLD_GLOBAL)

before loading NLopt

@porterjamesj
Copy link
Author

👍 that seems to do the trick.

@StefanKarpinski
Copy link
Contributor

Can this issue be closed?

@mlubin
Copy link
Member

mlubin commented Jan 8, 2014

Not really, it shouldn't be needed to explicitly call dlopen("libstdc++",RTLD_GLOBAL). This is an issue with all homebrew binaries when using Julia built from source on 10.9.

@staticfloat
Copy link
Contributor

I'm not sure what the proper solution for this is. Here are our options:

  • Change our OSX build process so that building from source on 10.9 uses libstdc++ by default. I thought we had already done this, but apparently not. Note that this would require all dependencies to also do this, as mixing stdlib's in the same process is generally considered a bad idea, although I don't have concrete reasons as to why that's bad.
  • Automatically determine when Julia has been built on something other than libstdc++ and just run dlopen("libstdc++", RTLD_GLOBAL) on startup. This seems like the most hackish way of dealing with this, and if I knew why mixing stdlibs was a bad idea, I would know why we shouldn't do this.
  • Maintain separate binary distributions (of both Julia and Homebrew deps) for 10.8- and 10.9+. This is what Homebrew, etc. does.

@mlubin
Copy link
Member

mlubin commented Jan 9, 2014

What's a bit confusing to me is why these shared libraries don't have an explicit dependency on libstdc++. If they did, then it would be automatically loaded with private visibility and we wouldn't have this issue.

@staticfloat
Copy link
Contributor

Strangely enough, most software I can find DO have explicit dependencies on either libstdc++ or libc++. Perhaps we can pass some compiler option to get this to happen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants