I'm working on a gem that I want to be able to run on older versions of ruby. I'm having...issues. (I'm on Mint 19.)
Uninstalling libssl-dev and installing libssl1.0-dev, along with setting CC=gcc-4.8 (the oldest that ships with Mint 19) allowed me to build 1.8.7-p375. Oddly enough, 1.9.0 & 1.9.1 failed, while I was able to get 1.9.2-p330, 1.9.3-p551 and 2.0.0-p648 as well as later 2.x series.
My concern is not so much about my builds today, as what rbenv's policy should be regarding old builds.
One option is to declare that when a version goes out of support officially, rbenv no longer cares about it. That makes me sad, but it is certainly defensible.
Another option is to try to keep up. I expect that there is some non-drastic way to pull in the libssl1.0-dev library into the build for the older versions that are using it. That's easy for today, but as I have already experienced, the mass is much more than that.
Another option would be to keep some sort of tweeks datasheet or perhaps a known good datasheet with data on the major distributions & OSes. For instance, what versions of gcc, yacc/bison, libssl-dev, & etc are known to work. In the event of a failed build, rbenv could reference such a document (or even check against it) to aid the end user.
The current model, where the fail happens with some sort of compiler error that may or may not send you off in a useful direction seem..less than optimal.
In any event, a clearly stated policy would seem to be in order.
I love your work, btw. Thanks.
I'm working on a gem that I want to be able to run on older versions of ruby. I'm having...issues. (I'm on Mint 19.)
Uninstalling libssl-dev and installing libssl1.0-dev, along with setting CC=gcc-4.8 (the oldest that ships with Mint 19) allowed me to build 1.8.7-p375. Oddly enough, 1.9.0 & 1.9.1 failed, while I was able to get 1.9.2-p330, 1.9.3-p551 and 2.0.0-p648 as well as later 2.x series.
My concern is not so much about my builds today, as what rbenv's policy should be regarding old builds.
One option is to declare that when a version goes out of support officially, rbenv no longer cares about it. That makes me sad, but it is certainly defensible.
Another option is to try to keep up. I expect that there is some non-drastic way to pull in the libssl1.0-dev library into the build for the older versions that are using it. That's easy for today, but as I have already experienced, the mass is much more than that.
Another option would be to keep some sort of tweeks datasheet or perhaps a known good datasheet with data on the major distributions & OSes. For instance, what versions of gcc, yacc/bison, libssl-dev, & etc are known to work. In the event of a failed build, rbenv could reference such a document (or even check against it) to aid the end user.
The current model, where the fail happens with some sort of compiler error that may or may not send you off in a useful direction seem..less than optimal.
In any event, a clearly stated policy would seem to be in order.
I love your work, btw. Thanks.