Implications of --enable-shared config

ruby-talk
1

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?

Thanks in advance for the help!

···

--
Posted via http://www.ruby-forum.com/.

2

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?

It's a little slower (we're having a discussion in ruby-core related
to it, too).

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/60378

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).

···

Jess Trang <lists@ruby-forum.com> wrote:

3

Thanks for the replies Eric!
My responses inline.

Eric Wong wrote in post #1135149:

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?

It's a little slower (we're having a discussion in ruby-core related
to it, too).

[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/60378

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.

TBH I'm not sure how many others exist, nor how widespread, but these
two came to my attention:
https://rubygems.org/gems/diff_match_patch
http://rubygems.org/gems/rice

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?

···

Jess Trang <lists@ruby-forum.com> wrote:

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).

--
Posted via http://www.ruby-forum.com/\.

4

Thanks for the replies Eric!
My responses inline.

Eric Wong wrote in post #1135149:
>> 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?
>
> It's a little slower (we're having a discussion in ruby-core related
> to it, too).
>
> [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/60378

Do you mean the compilation is slower or ruby execution itself is a bit
slower?

Startup + execution are slower. Not sure about compilation, but I
wouldn't obsess over that (see below)

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.

TBH I'm not sure how many others exist, nor how widespread, but these
two came to my attention:
https://rubygems.org/gems/diff_match_patch
http://rubygems.org/gems/rice

Try it, I suspect they'll work without --enable-shared.

> 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?

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.

···

Jess Trang <lists@ruby-forum.com> wrote:

> Jess Trang <lists@ruby-forum.com> wrote: