Closed coder543 closed 5 years ago
Thanks for reporting this. I'll look into it soon.
Alright. Ruby itself did away with having a static library file available by default here: https://bugs.ruby-lang.org/issues/12845 But I've found the RVM (Ruby Version Manager), which I use currently, keeps a copy of the libruby-static.a
files under .rvm/src/ruby-#.#.#/
.
What this means is that we'll need to implement support for all of the different ruby version managers out there and also default installs. As I have RVM I will go ahead and implement support for it under that but we'll need other people to create PRs for adding support for the different scenarios.
I was able to get static builds to work. 3 methods in this library currently don't work with it when statically linked and it seems statically linking things makes your code run slower. A few more things to do before I merge in the updates.
Alright, static builds now work with Rutie 0.4.1. Notes have been added to build.rs
.
The build.rs script implies that it supports static builds, but the binary that is built is definitely not static with respect to Ruby. I have a fork of ruby-sys that I was using with ruru that allows for truly static builds: https://github.com/coder543/ruby-sys/commits/master
I don't remember exactly where I found the discussions that led to the fork I made, but this is unfortunate. I want to use rutie so I can use binary Ruby strings properly... but I also can't deploy ruby gems that depend on libruby.so.
using
ldd ./target/release/whatever.so
it's possible to see what dynamic dependencies the executable has.