Attempt to fix #6327

[tknopp]

Try to fix #6327 and make the embedding docu a little bit more clear.

[samuelcolvin]

Not sure LD_LIBRARY_PATH is the most useful way of doing things, why not reference -Wl,-rpath,'/path/to/julia/usr/lib'?

[tknopp]

Is it really that common to hardcode the path to the shared library that is linked to? I did not even know that there is an option to do this until I read that here.

[jakebolewski]

Relative path linking is uncommon in Linux, it only makes sense if you are shipping an application and don't care about interoperability with package management systems .

[samuelcolvin]

Both LD_LIBRARY_PATH and -Wl,-rpath,'/path/to/julia/usr/lib' require a hardcoded path to the shared library dir. In fact only the Wl option allows for relative paths (via $CONFIG).

But there's another very good reason not to use LD_LIBRARY_PATH, on Ubuntu at least, the following:

export LD_LIBRARY_PATH=/usr/lib32:$JULIA/usr/lib
python3 -c "import readline"
>> ImportError: /home/samuel/julia/usr/lib/libreadline.so.6: undefined symbol: UP

This means ipython3 can't load readline and doesn't run properly (for some reason python2.7 still manages fine).

In short adding $JULIA/usr/lib to LD_LIBRARY_PATH can mess up your whole systems dynamic library loading.

(not sure if this particular library conflict counts as a separate issue which should be raised?)

[tknopp]

I don't know exactly what the issue here is and I absolutely do not want to start a discussion whether it is better to use LD_LIBRARY_PATH or -Wl,-rpath because this has nothing to do with Julia. The docu is also written for Windows users where it is also common to put the dll path to the PATH variable.

But I don't have commit rights anyway so it should be decided by @JeffBezanson or @StefanKarpinski how to make this documentation better.

To your particular problem.

1. I would never override LD_LIBRARY_PATH but use export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:JULIA/usr/lib
2. The particular readline issue should not happen when you use current master. libreadline is not used anymore
3. In the "regular user" world, Julia would use system libraries under linux so that these issues would not arise. I don't know if the Julia linux packages are already there but I would consider conflicting libraries as an issue that should be solved.

[cmundi]

Yes. rpath is used often to facilitate "local" installs with a defined set of directories under a relocatable root. Especially handy if you have multiple builds. The julia examples dir works this way.

[cmundi]

Ok, I was looking at this again and I think there are a some things which can be done to make the embedding docs slightly clearer:

• place stronger emphasis on the phrase when [sic] Julia is installed to $JULIA_DIR so that it is clear that we are talking about an install and not a julia dev directory. A reader who misses this point may become confused trying to find the headers and libs.
• for example, export JULIA_DIR=<julia_dev_home>/julia-1651d99ec7
• then the command line becomes gcc -o test -I$JULIA_DIR/include/julia -L$JULIA_DIR/lib/julia -ljulia test.c

The notes above are essentially platform independent and assume only that the user is compilng with gcc. Shared library resolution is (potentially) platform-dependent or at least distribution-dependent. While I imagine that eventually make install will be revised to perform a system-wide install, in the meantime I added an /etc/ld.so.conf.d/libjulia.conf pointing to a julia directory which is a symlink I can direct to whatever julia-<commit-hash> I want at the moment. Then of course I sudo ldconfig.

While this approach is a little clunky, it is at least transparent. It should at least be clear what changes are needed for other platforms, which may avoid some frustration. This also eliminates the need for rpath.

I think the main point is that anyone embedding julia will need to decide whether to piggy-back on a system-wide julia or ship a local copy. The suggestions above are meant to be consistent with the spirit of the Embedding Julia section of the manual, which I perceive as illustrating capability and not providing deployment advice

[mlubin]

People using package-manager installed versions of Julia should have the headers and libraries already in the default paths.

[cmundi]

Agreed. Is any major distro shipping Julia yet? Must admit I haven't looked.

I also forgot to say that I prefer not to resort to LD_LIBRARY_PATH just
because I prefer to keep my shell environment as clean as possible to
minimize surprises.

People using package-manager installed versions of Julia should have the
headers and libraries already in the default paths.

—
Reply to this email directly or view it on
GitHubhttps://github.com//pull/6455#issuecomment-41869095
.

[nalimilan]

Debian already ships Julia, and a Fedora package is under way.

[quinnj]

Still relevant? I would think our embedding docs have come a long way since this PR...