OS X 10.13.3 exposes bad fork() issue

After updating to OS X 10.13.3, I received the following error trying to require 'vips':

objc[25602]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called.
objc[25602]: +[__NSCFConstantString initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

Some googling took me to this post, which explains that the error comes from “incorrect code that happened to work most of the time in the past.” I have no way of knowing whether the issue is in ruby-vips or ffior libvips itself, and I don't really have the time or knowledge to track it down. Using one of that page's suggested workarounds – setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES in the environment – allowed me to load ruby-vips without issue and get on with my work, though I realize I'm just asking OS X to hang later if it encounters a deadlock instead of crashing the process now.

I'm reporting it here so there's both an issue to track and a concise explanation and workaround for anyone else who happens to google this error in a vips context.

Start by reproducing the failure at require 'vips' on OS X 10.13.3, with and without OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES. Trace whether the fork failure belongs to ruby-vips, ffi, or libvips; done means identifying the responsible component and providing a safe fix or documented workaround.