Add support for dlvsym(3)

[smortex]

This PR add support for dlvsym(3) to jffi.

The function dlvsym(3) does the same as dlsym(3) but takes a version string as an additional argument. This is useful for accessing a previous version of a function when a library evolves.

[smortex]

\o/ I managed to have the whole stack working as expected!

Some cleanup / advises from people used to Java should help make this perfect, thanks! I'll review my changes to spot the points where I am not sure of what I did.

[smortex]

@headius thanks for the review, all big question marks on the top of my head have vanished (or at least I guess so).

I look forward for this to be merged to attempt fixing the next layer of code, probably with annotations? (don't know, never programmed in Java before)

[headius]

@smortex What platforms will need new binaries for this?

We really need to get some cross-platform build rig set up, because the need to rebuild all the native binaries is really holding us back.

[smortex]

@headius I guess all platforms will need the updated bits in jni/jffi/Library.c wrapping dlvsym() in native code so that the code in src/main/java/com/kenai/jffi/Library.java can make use of it?

I do not really know how to help with producing and testing these changes on other operating systems. For a FreeBSD project, I have used https://cirrus-ci.com/ once, which has supports for running code on FreeBSD. Maybe this can be an option?

[smortex]

I have looked into building the project on FreeBSD with Cirrus-CI:

• smortex@727e0bb
• https://cirrus-ci.com/build/5212701570629632

The doc says we can do things with artifacts. May this be (part of) a solution?

[headius]

@smortex Yeah that's a pretty compelling option, with Mac, Linux, Windows, FreeBSD available!

At the very least we could start throwing some CI up there and start looking at how to reintegrate the artifacts that get built. The idea being that we would test on a local system (where presumably we can build native lib) and then push to CI, which would use Cirrus and others to test across all the other platforms, building their binaries in the process.

I'm game to give Cirrus a try on master and see what we can do with it.

[headius]

Marking for 2.0 as I think that will be the logical leap forward with the native binary. We will build in fallbacks to old behavior when the binary has not been updated, and build for as many platforms as possible whenever it changes, but we need to be able to move the native bits forward.

[headius]

@smortex This has gotten pretty old but if you're still out there we have an opportunity to start adding to the native binary. I will need to rework some things to do varargs calls the "correct" way, which will mean a rolling rebuild of all binaries. This could pull in additions to the API to better support things like dlvsym.

[smortex]

Hi @headius!

Feel free to mess-up with this PR (and the other ones from me! 😉). My Java knowledge is rather limited and you seem to have a pretty good idea of the direction this should take. Let me know if I need to do something to make your life easier.

Thanks!