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

Show unusual dlerrors #7940

Closed
wants to merge 1 commit into from

Conversation

ihnorton
Copy link
Member

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
Copy link
Member

Keno commented Aug 10, 2014

👍

@tkelman
Copy link
Contributor

tkelman commented Aug 10, 2014

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

@ihnorton
Copy link
Member Author

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
Copy link
Member

vtjnash commented Aug 12, 2014

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
Copy link
Member

Keno commented Aug 12, 2014

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

@vtjnash
Copy link
Member

vtjnash commented Aug 12, 2014

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

@Keno
Copy link
Member

Keno commented Aug 14, 2014

Ok, let's try that approach.

@ihnorton
Copy link
Member Author

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
Copy link
Member

Keno commented Aug 14, 2014

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

@ihnorton
Copy link
Member Author

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
Copy link
Member

vtjnash commented Aug 30, 2014

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
Copy link
Member Author

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

@vtjnash
Copy link
Member

vtjnash commented Aug 30, 2014

right

@jiahao jiahao force-pushed the master branch 2 times, most recently from 2ef98c5 to 0388647 Compare October 5, 2014 00:57
@Keno
Copy link
Member

Keno commented Oct 6, 2014

BUMP :)

@tkelman
Copy link
Contributor

tkelman commented Mar 25, 2015

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

@ihnorton
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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.

@ihnorton ihnorton deleted the show_unusual_dlerrors branch September 26, 2023 03:34
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

Successfully merging this pull request may close these issues.

5 participants