bug#38500: Ruby is built against libruby-static.a

bug#38500: Ruby is built against libruby-static.a

[Vicente Eduardo]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

I'm trying to use Ruby interpeter as a library to link it against my
project (metacall:
https://github.com/metacall/distributable/blob/65493b393388f5d66d9b466e5d49f9128fee27ea/source/metacall.scm#L117
). So I tried to download the Ruby package and libruby.so seems not to be
present.

Running ldd against ruby executable shows that it is linked with
libruby-static.a. When I do ldd against Ruby on my Debian system, it is
linked dynamically to libruby.so.

I would like to have two versions, or at least the dynamic one, that's the
common way Ruby should be built, and also the Guixy style.

If this isn't handled, I will have to inherit the package and modify the
compilation flags in order to compile Ruby with the dynamic library version.

Thanks.

[-- Attachment #2: Type: text/html, Size: 1097 bytes --]

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Vicente Eduardo <vic798@gmail.com> writes:

> I would like to have two versions, or at least the dynamic one, that's the common way
> Ruby should be built, and also the Guixy style.

This actually brings up a rather interesting point. What is the Guix
protocol on compilation for dynamic vs statically linked interpreters?
This is a prevalent issue not just for Ruby, but for also how we handle
GHC, Rust, JDK, and so on.

Generally, I think we dynamically link most objects. _BUT_, I could be
missing part of the story here. So I am going to wait for the higher
powers that be to respond.

In the mean time, when I get a moment, I will do some auditing on this
package to see if the issue is just that we are missing some compilation
procedure. Hopefully it is just as simple as that, but I still think the
issue of linkage style (dynamic vs static linkage) remains prevalent.

Hopefully we hear some noise on this soon.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Vicente Eduardo]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

Python and Ruby link dynamically by default from the executable of the
runtime to the runtime library. Most runtimes do that, it is a good design
that allows reusing the runtime to the embedders. As exception of NodeJS
which avoids this because of a design decision related to the distribution,
and because it hasn't got an embedding API and an stable extension API
(N-API) until 8.x, and Rust, due to lack of ABI stability.

I didn't check GHC and Java yet, but most languages that have extension and
mainly embedding API do that (JVM has embedding and extension API).

I am not an expert about Guile but I can  check the configure/Makefile of
Ruby in order to see what flags do it need to compile against the dynamic
library, and providing the static too as Debian distribution does for Ruby
(or Guix itself for Python and libpython3.7m.so).

El sáb., 7 dic. 2019 17:44, Brett Gilio <brettg@posteo.net> escribió:

> Vicente Eduardo <vic798@gmail.com> writes:
>
> > I would like to have two versions, or at least the dynamic one, that's
> the common way
> > Ruby should be built, and also the Guixy style.
>
> This actually brings up a rather interesting point. What is the Guix
> protocol on compilation for dynamic vs statically linked interpreters?
> This is a prevalent issue not just for Ruby, but for also how we handle
> GHC, Rust, JDK, and so on.
>
> Generally, I think we dynamically link most objects. _BUT_, I could be
> missing part of the story here. So I am going to wait for the higher
> powers that be to respond.
>
> In the mean time, when I get a moment, I will do some auditing on this
> package to see if the issue is just that we are missing some compilation
> procedure. Hopefully it is just as simple as that, but I still think the
> issue of linkage style (dynamic vs static linkage) remains prevalent.
>
> Hopefully we hear some noise on this soon.
>
> --
> Brett M. Gilio
> https://git.sr.ht/~brettgilio/
>

[-- Attachment #2: Type: text/html, Size: 2585 bytes --]

bug#38500: Ruby is built against libruby-static.a

[Vicente Eduardo]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

I have checked the flags needed for compiling dynamically.

It should be very easy to solve, just by adding this flag to the configure:

--enable-shared

This should be enough to compile Ruby runtime dynamic library and to
compile Ruby interpeter executable against this lib.

Reference:
https://github.com/ruby/ruby/blob/0d63a2104777e467568a31037a6573e1879870c7/configure.ac#L3136


El dom., 8 dic. 2019 15:44, Vicente Eduardo <vic798@gmail.com> escribió:

> Python and Ruby link dynamically by default from the executable of the
> runtime to the runtime library. Most runtimes do that, it is a good design
> that allows reusing the runtime to the embedders. As exception of NodeJS
> which avoids this because of a design decision related to the distribution,
> and because it hasn't got an embedding API and an stable extension API
> (N-API) until 8.x, and Rust, due to lack of ABI stability.
>
> I didn't check GHC and Java yet, but most languages that have extension
> and mainly embedding API do that (JVM has embedding and extension API).
>
> I am not an expert about Guile but I can  check the configure/Makefile of
> Ruby in order to see what flags do it need to compile against the dynamic
> library, and providing the static too as Debian distribution does for Ruby
> (or Guix itself for Python and libpython3.7m.so).
>
> El sáb., 7 dic. 2019 17:44, Brett Gilio <brettg@posteo.net> escribió:
>
>> Vicente Eduardo <vic798@gmail.com> writes:
>>
>> > I would like to have two versions, or at least the dynamic one, that's
>> the common way
>> > Ruby should be built, and also the Guixy style.
>>
>> This actually brings up a rather interesting point. What is the Guix
>> protocol on compilation for dynamic vs statically linked interpreters?
>> This is a prevalent issue not just for Ruby, but for also how we handle
>> GHC, Rust, JDK, and so on.
>>
>> Generally, I think we dynamically link most objects. _BUT_, I could be
>> missing part of the story here. So I am going to wait for the higher
>> powers that be to respond.
>>
>> In the mean time, when I get a moment, I will do some auditing on this
>> package to see if the issue is just that we are missing some compilation
>> procedure. Hopefully it is just as simple as that, but I still think the
>> issue of linkage style (dynamic vs static linkage) remains prevalent.
>>
>> Hopefully we hear some noise on this soon.
>>
>> --
>> Brett M. Gilio
>> https://git.sr.ht/~brettgilio/
>>
>

[-- Attachment #2: Type: text/html, Size: 3708 bytes --]

bug#38500: Ruby is built against libruby-static.a

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Vincente, Brett,

Brett Gilio 写道：
> Vicente Eduardo <vic798@gmail.com> writes:
>
>> I would like to have two versions, or at least the dynamic one, 
>> that's the common way
>> Ruby should be built, and also the Guixy style.

Important: static linking isn't the Guixy style at all!

Statically linking different packages ‘subverts’ Guix, can subvert 
grafting and lead to undetected security holes.

> Generally, I think we dynamically link most objects.

Correct.

> _BUT_, I could be
> missing part of the story here. So I am going to wait for the 
> higher
> powers that be to respond.

You could ask Pjotr Prins and David Thompson but I suspect that it 
was simply an oversight: most packages link dynamically by default 
because it's the sane thing to do, and it would have been 
reasonable to assume Ruby did too.

If there is a good reason to link statically, it should be added 
in a comment.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> You could ask Pjotr Prins and David Thompson but I suspect that it was
> simply an oversight: most packages link dynamically by default because
> it's the sane thing to do, and it would have been reasonable to assume
> Ruby did too.

Tobias,
I did some investigating about enabling the --enable-shared flag for
dynamic linkage of the Ruby package. Superficially it seems that simply

--8<---------------cut here---------------start------------->8---
#:configure-flags (list "--enable-shared")
--8<---------------cut here---------------end--------------->8---

takes care of the issue. However, this will trigger a rebuild more along
the lines of core-updates.

--8<---------------cut here---------------start------------->8---
Building the following 1261 packages would ensure 3512 dependent
packages are rebuilt:
--8<---------------cut here---------------end--------------->8---

It is basically everything from SBCL, R, GNOME, XFCE, several Python
packages, and more which is expected.

So I guess the question is where does this patch go given that it isn't
an update but would still spark a massive rebuild?

&&&

Vicente,
I have a suspicion that this patch will need to rest on core-updates (or
staging) for a number of weeks before it reaches master. In the
meantime, I suggest you just inherit the ruby package in your own
channel with the package arguments modified to reflect the
`#:configure-flags` snippet I have listed above.

Okay. Carry on.

-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

I have submitted a patch that will go into core-updates, with bug report
#38552. That patch will close both of these bug reports.

Thanks.
-- 
Brett M. Gilio
https://git.sr.ht/~brettgilio/

bug#38500: Ruby is built against libruby-static.a

[Brett Gilio]

Pushed to core-updates with fd248cb815d571043c3a0c52a01c9b3e368a069e.

Closing

-- 
Brett M. Gilio
Homepage -- https://scm.pw/
GNU Guix -- https://guix.gnu.org/