add DLopen extension #52
Conversation
lamont-granquist
commented
Mar 27, 2015
lamont-granquist
commented
- adds dlopen extension to remove janky searching through modules to find a dlopen.
- removes more FFI code from the ext path
- better and easier to understand logic for trying multiple dynamic lib names than the FFI routine
- directly fixes .bundle/.dylib issues on mac
- should fix algorithm so that USE_SYSTEM_LIBYAJL2 env var works as intended
- docs for USE_SYSTEM_LIBYAJL2
This will get dlopen in a consistent place on all the platforms which need it.
lamont-granquist
force-pushed
the
lcg/dlopen-extension
branch
from
6f337d3 to
9a53602
Compare
run through multiple different possible library names and extensions, favoring the libyajl2 gem versions first.
jruby can't load this
|
@chef/client-core @chef/client-engineers needs review |
|
👍 slight concern that there could be some bizzare way that the code would fail without the other yajl library loaded but we wouldn't see that in testing since we always load it for testing now, but that's probably not very likely. |
|
Hah, I had not considered that. Its much more likely that we get segfaults when we load both c-libs into the same process (which used to happen on linux/ubuntu without ffi for some reason). We'll also get ffi-yajl tested without ruby-yajl in the chef-client tests themselves before we ship chef + chefdk, so we should get coverage at that step (we might release a busted ffi-yajl gem but shouldn't ship a busted chef or chefdk) |
|
Yep, I think this is the right way to go, just making a note that it makes me twitch when we test based on a state other than what we expect to be the state in "production" use. And you're correct that the risk is well mitigated elsewhere. |
