-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Get additional library paths from ldconfig on Linux #478
Conversation
Interesting approach. Seems like a good idea, although this patch could stand some tests (even if platform-specific). |
This is twall's jna git, commit a82a6ca (post release 4.1.0), with my path ("Get additional library paths from ldconfig on Linux"), commit f0ea52c, on top. Upstream PR: java-native-access/jna#478
I'll test it tomorrow on Raspbian (armv6hf Debian), and also on my laptop (amd64 Fedora). Will report back. |
A little OT, but does it make sense to have HF/non-HF versions of the JNA ARM build?
|
…aths from ldconfig This should preserve existing behavior more closely.
@twall I don't know enough about the compatibility between different ARM ABIs and JNA to comment on that.. the best description of the situation I have found is was here. My understanding is that both Debian and Fedora settled on armv7 as their baseline for a "hard float" ABI, and that Raspbian is rolling its own armv6hf port, since that was was the highest the original Raspberry Pi could support. I believe that armv6hf binaries run on armv7hf distributions, but not vice versa, but I could be wrong. |
There's definitely also a armv6 (without the hard-float) ABI that one comes across occasionally. |
This is now twall's jna git, commit a82a6ca (post release 4.1.0), with my patches ("Get additional library paths from ldconfig on Linux"ff), commit 8c067a2, on top. Upstream PR: java-native-access/jna#478
Tested today. Worked as expected. Think it's a step up from the current behavior, but I might be biased :) |
} | ||
} | ||
reader.close(); | ||
} catch (Exception e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be concerned about a catch all here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dblock Ain't pretty - but my reason for this was that I don't ever want this code to regress from the paths, and functionality, it offers currently. There are a number of reasons why the code above could fail, either now, or by some changes to ldconfig down the road. This at least makes sure that we don't trip on them...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you aware of any execution restrictions on /sbin/ldconfig
? SE Linux in particular sometimes has some reduced availability of system-oriented functions.
@twall My Fedora (22) had SE Linux enabled (and was enforcing it), but I didn't see any warnings or the like. This is not to say that this couldn't be a problem, just that I haven't seen it. What would be the default action if SE Linux is indeed not happy about an application invoking |
My guess would be that either the program would be invisible to a normal user or that invoking it would just fail. So presumably the generic exception net would catch such failures. |
Get additional library paths from ldconfig on Linux
This is twall's jna git, commit a82a6ca (post release 4.1.0), with my path ("Get additional library paths from ldconfig on Linux"), commit f0ea52c, on top. Upstream PR: java-native-access/jna#478
This is now twall's jna git, commit a82a6ca (post release 4.1.0), with my patches ("Get additional library paths from ldconfig on Linux"ff), commit 8c067a2, on top. Upstream PR: java-native-access/jna#478
No description provided.