Show unusual dlerrors

[ihnorton]

This is an issue as much as a PR. jl_load_dynamic_library is quite helpful in that it tries hard to find a shared library: every path in DL_LOAD_PATH is tried with all the possible extensions appended for a given platform. For non-throwing invocations (throw_err = 0), this usually leads to shadowing any "real" loading errors and instead printing cannot open shared object file: No such file or directory --- because that is most often the last thing that happened in the stack of file permutations. In this PR, the error string is checked, and anything other than the No such file message is shown as a warning. For example, with this PR I get:

WARNING: while loading libcxxffi-debug: /home/isaiah/.julia/Cxx/src/../deps/usr/lib/libcxxffi-debug.so: undefined symbol: _ZN4llvm18format_object_base4homeEv

Whereas previously ... No such file... was shown. Situations where this applies include find_library and ccall-initiated dl-searches.

[Keno]

👍

[tkelman]

Whole bunch of warnings on Mac Travis WARNING: while loading libopenblas: dlopen(@executable_path/../lib/julia/libopenblas, 1): image not found

[ihnorton]

Yeah, probably would need to check for that too and any different message
on Windows (haven't looked yet).

On Sun, Aug 10, 2014 at 10:21 AM, Tony Kelman notifications@github.com
wrote:

Whole bunch of warnings on Mac Travis WARNING: while loading libopenblas:
dlopen(@executable_path/../lib/julia/libopenblas, 1): image not found

—
Reply to this email directly or view it on GitHub
#7940 (comment).

[vtjnash]

how about instead of trying to parse error messages, just adding a call to jl_stat to decide if the file exists before calling uv_dlopen?

[Keno]

That's not sufficient. Some systems also tell you if dependent libraries are missing and if so which.

[vtjnash]

It's sufficient for that case, since you would know the file exists, and then care about possibly showing that error message

[Keno]

Ok, let's try that approach.

[ihnorton]

jl_stat fails for any path-less library names that could otherwise be found in the LD search paths, so I don't think that will work.

(though I'm not crazy about parsing error messages, either)

[Keno]

That's a fair point. Can we look at the error code rather than the error message?

[ihnorton]

I was wondering about that, but libuv doesn't seem to have useful error codes:
uv_dlopen expects a path to the shared library and sets the opaque uv_lib_t pointer. It returns 0 on success, -1 on error. Use uv_dlerror to get the error message.

[vtjnash]

it doesn't appear the dlopen has error codes, so uv_dlopen can't do much about that.

but perhaps you could lookup a known invalid location (tmpnam?) & cache the result

[ihnorton]

I take it you mean the resulting error string, so that we don't have to worry about cross-platform differences?

[vtjnash]

right

[Keno]

BUMP :)

[tkelman]

This might help JuliaPackaging/BinDeps.jl#126 become more useful too...

[ihnorton]

Sorry, I'll get to this soon. I think I ran in to issues trying to use the cache-the-error-message strategy on different platforms. Probably would be better to Do The Right Thing and expose the error in libuv.

[JeffBezanson]

This would be nice to have. Maybe we can just hack in a list of things to search for with strstr to exclude boring errors. If you see a dlerror you don't like, add it to the list.

[ihnorton]

Trying a different approach to make this better. Parsing error messages just makes me sad, and will also often exclude an actually-correct error message.