I’m building a lot of ruby servers - I just want to understand if there
are any negative implications of configuring with the “–enable-shared”
option?
The “–enable-shared” option will “build a shared library for Ruby” and
I
understand there are some apps/gems that require option to be set to
give them access to native stuff via ruby.
Essentially I can not find any negative impact to using it, but then I
don’t quite follow why it isn’t enabled by default…?
For instance could there be some implications if I build with
“–enable-shared” and then update packages on the server (or even
rebuild a new version) at a later date - could this cause orphan issues
or anything?
The “–enable-shared” option will “build a shared library for Ruby” and
I
understand there are some apps/gems that require option to be set to
give them access to native stuff via ruby.
Which ones? gems can link to the static library just fine in the
default install.
Most Linux distributions will package a shared one to save space and
improve upgradability, though. There is no need to rebuild all C
extension gems to fix a bug in dynamic libruby.
Essentially I can not find any negative impact to using it, but then I
don’t quite follow why it isn’t enabled by default…?
Dynamic libraries are still a little slower (you may not notice).
For instance could there be some implications if I build with
“–enable-shared” and then update packages on the server (or even
rebuild a new version) at a later date - could this cause orphan issues
or anything?
It’s probably more prone to human error in case you use different
build options (or Ruby developers accidentally break something :x).
Do you mean the compilation is slower or ruby execution itself is a bit
slower?
I’ll go check out the ruby-core thread.
The “–enable-shared” option will “build a shared library for Ruby” and
I understand there are some apps/gems that require option to be set to
give them access to native stuff via ruby.
Which ones? gems can link to the static library just fine in the
default install.
Most Linux distributions will package a shared one to save space and
improve upgradability, though. There is no need to rebuild all C
extension gems to fix a bug in dynamic libruby.
Essentially I can not find any negative impact to using it, but then I
don’t quite follow why it isn’t enabled by default…?
Dynamic libraries are still a little slower (you may not notice).
Is that a once-off hit to load the library, or are we talking an ongoing
performance hit?
For instance could there be some implications if I build with
“–enable-shared” and then update packages on the server (or even
rebuild a new version) at a later date - could this cause orphan issues
or anything?
It’s probably more prone to human error in case you use different
build options (or Ruby developers accidentally break something :x).
Try it, I suspect they’ll work without --enable-shared.
performance hit?
Ongoing, but really, you wouldn’t notice the performance unless you’re
microbenchmarking (like we are in that ruby-core thread).
Also, on any GNU/Linux system (and probably most other OSes), dynamic
linking is widespread beyond Ruby (so stuff like libc, zlib, etc) are
all dynamically linked; and you’re paying the performance hit for that
(but also saving some memory/cache due to sharing).
Anyways you’ll find a lot on the web about the tradeoffs for/against
dynamic linking.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.