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

ZMQ Shared Library Location #37

Closed
quinnj opened this issue Nov 25, 2013 · 10 comments
Closed

ZMQ Shared Library Location #37

quinnj opened this issue Nov 25, 2013 · 10 comments

Comments

@quinnj
Copy link
Contributor

quinnj commented Nov 25, 2013

Not sure if this is the right place, but I'm trying to iron out some wrinkles in the IJulia frontend in Sublime Text. I have a sublime plugin that loads the ZMQ from the IJulia package install, but it seems that the ZMQ library doesn't always get put in the same place. So far, it looks like windows and linux both get the library in .julia/ZMQ/deps/usr/lib, but osx (through homebrew) installs it in the usr/local directory, but sometimes in different directories? (a question because I'm not exactly sure what happens here other than I've had 2 people find it in different places on their system).

Is there a reliable and cross-platform way to find the shared library after a user has successfully built/installed ZMQ/IJulia?

@StefanKarpinski
Copy link
Contributor

cc: @loladiro, @staticfloat

@Keno
Copy link
Contributor

Keno commented Nov 25, 2013

ZMQ.zmq from Julia, other than that no, since we have given up on uniform installation locations.

@StefanKarpinski
Copy link
Contributor

That's an unfortunate situation. Can we do something about that so that we do have uniform installation locations?

@Keno
Copy link
Contributor

Keno commented Nov 25, 2013

No, that's pretty much totally unfeasibly, especially since we try to use system libraries where possible.

@staticfloat
Copy link
Contributor

Different OS'es have different standards, so like @loladiro says we don't really do uniform installation locations, especially since if users already have a working libzmq on their system BinDeps won't even try to build it again, so it might not even be in the ~/.julia/ directory at all.

I would really like a way to turn a dlopen()'ed handle into a library path, but as of yet we don't have anything like that. The closest thing we do have is this PR I just opened.

@StefanKarpinski
Copy link
Contributor

@loladiro – are you talking about the libraries we install or the system libraries? My impression is that the issue here is that we are installing libraries under .julia in inconsistent places across different operating systems. If dlopen is able to find libraries, then other things must also be able to do so, in which case, can't we expose that information to the user?

@StefanKarpinski
Copy link
Contributor

Ah, you already answered my question by the time I posted it. Thanks, @staticfloat and @loladiro.

@quinnj
Copy link
Contributor Author

quinnj commented Nov 25, 2013

So for this situation though, if the user has successfully built ZMQ/IJulia, that means they either have the shared library in the deps/usr/lib directory (sometimes on linux, probably always on windows), or will be a system library. In the case of the latter, does that mean the library will be available on the path? (I'm trying to think through how I can reliably check/find the library....). I guess if not, I can just have a package setting where the user can specify their zmq shared library path, though I was hoping to avoid having to do that at all.

@Keno
Copy link
Contributor

Keno commented Nov 25, 2013

You can have that option and auto-populate it with the value of ZMQ.zmq.

@quinnj
Copy link
Contributor Author

quinnj commented Nov 25, 2013

Yeah, that should work. I was thinking of having a script run to install IJulia if it wasn't anyway, so I'll fold the ZMQ finding in as well. Thanks for the responses.

@quinnj quinnj closed this as completed Nov 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants