Hm 
Your approach is almost identical with the one I had - the only difference I spot is when you call __crystal_init. You do it when you initialise the ruby extension, I did it, just whenever I would call any Crystal code for the very first time. I don’t see why one should work while the other one shouldn’t - but it obviously does, so I’ll give it another try (also: your approach is far more convenient to use, than to track and check if it has been initialised already like I did).
EDIT: I just tried your code (first I adjusted mine to call things at the same time as you do, but as this didn’t work either, I directly copy pasted things from here), and it still gives me the same segmentation fault. So I guess it’s actually really related to something else (as the few gems I use which have a C extension, don’t have a problem, I suspect it’s one of the libraries crystal requires which don’t do well with my ruby version).
Irrelevant for this, but it confused me a lot, and maybe you experienced something similar (or can explain why this happened): With all the playing around, I once accidentally picked the wrong c file, which also had a main function. I was sure it would fail (because of duplicate symbols and my crystal file obviously had already a main included) but to my surprise it didn’t fail, it didn’t care about it at all. Do static dylibs handle duplicate symbols differently? And which one would get picked - is there a rule, undefined behaviour, or would it crash?
Similar: I also tried for a bit to remove symbols. Not that I had any reason to do so. I am new to all the linking stuff, so maybe I learn something along the way and in worst case I would just waste time. And then I played around with the strip tool, and removed several sections. To my surprise, even when I chose to remove like everything, by every available option I found, things still worked seemingly fine while I was able to shave approximately another 20% off my files (even though I had used already things like --no-debug etc for the crystal file before). nm -C wouldn’t show almost any symbols left (for the crystal file there were maybe 6 or 8 symbols left), but the linker accepted them anyway without any complains and things worked still just like before. First I thought the symbols would be maybe just like not advertised anymore or something like that, but as the file size decreased so significantly I guess quite a lot of the stuff must have been really removed.
Regarding export "C" yes and no. In the example, you are absolutely right, it would fully do the job. But when you do it with class methods then you already overstep a line (you can’t declare them static and extern). You also can’t just declare them outside of the class, like you can’t just do a static void Foo::bar(); it needs to be inside of class Foo { … but there you can’t tell it to be extern "C" and you aren’t allowed to put the whole class into a extern “C” block either. So for those you would have to deal with the name mangling anyway, and then I preferred to do it just for everything and have it all the same way.