Ruby is built against libruby-static.a

  • Done
  • quality assurance status badge
Details
3 participants
  • Brett Gilio
  • Tobias Geerinckx-Rice
  • Vicente Eduardo
Owner
unassigned
Submitted by
Vicente Eduardo
Severity
normal
V
V
Vicente Eduardo wrote on 5 Dec 2019 14:25
(address . bug-guix@gnu.org)
CAOUKKgE=KutdNR2KTFeAme_8qPoq9khx_9kroTFRFZwPUAiYUg@mail.gmail.com
I'm trying to use Ruby interpeter as a library to link it against my
project (metacall:
). 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: file
B
B
Brett Gilio wrote on 7 Dec 2019 17:44
(name . Vicente Eduardo)(address . vic798@gmail.com)(address . 38500@debbugs.gnu.org)
87fthwdr0p.fsf@posteo.net
Vicente Eduardo <vic798@gmail.com> writes:

Toggle quote (3 lines)
> 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
V
V
Vicente Eduardo wrote on 8 Dec 2019 15:44
(name . Brett Gilio)(address . brettg@posteo.net)(address . 38500@debbugs.gnu.org)
CAOUKKgHKMFhy-S6Xyo7XwLPQwoHkXD=TbeCTV3E6yjEF0R_2oA@mail.gmail.com
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ó:

Toggle quote (26 lines)
> 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: file
V
V
Vicente Eduardo wrote on 8 Dec 2019 15:49
(name . Brett Gilio)(address . brettg@posteo.net)(address . 38500@debbugs.gnu.org)
CAOUKKgHeQ2ZV7u3S_CuZe4dgrJSyMWrXrP5fpieOHuhXBcRSMQ@mail.gmail.com
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:


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

Toggle quote (44 lines)
> 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: file
T
T
Tobias Geerinckx-Rice wrote on 8 Dec 2019 16:42
87a782bz90.fsf@nckx
Vincente, Brett,

Brett Gilio ???
Toggle quote (6 lines)
> 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.

Toggle quote (2 lines)
> Generally, I think we dynamically link most objects.

Correct.

Toggle quote (5 lines)
> _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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl3tGdcACgkQ2Imw8BjF
STxP7g//Q2Q6IS6BCmEmdunGRZIbDquuU+btDA44/p+vhbBocOyDnI8cPwsVBsqt
1I70TsklZU1Wt7qhPn+RbGaLIMnVDc1phUgqO9pGY8pI6KeaFoUneYQjq6fgn2W0
S0COWrg2nCZCf7ReoJ6uhhcV+ma+23wOrJL1LgaCoSG+LtRyzn73dHsqVx/HQaKA
IZIX32QGhDF6siwcdytWtcWkeCC98wS2oZlCsn0hnQkwV+PY5eBig/MYqAvgUvaL
Nc7tEFdbGLUj7rfLrjFYTF7tJhbyC1MzPrnQ6+is1i5hrtdND2GW1R4KhmTsCuKV
c9WKvqPwxeotVg3BDGoOpNLOa+ZdgE535A9I8iZSqBllTek5ZYPcqdlp5bO8gUiq
n0d2pY+7mv8r46D01genvbCf4AFzj9/OYnQJK+5FTbidYClaG4iYQZlHvbc4zzlz
cap54+yP1ATlYkd5UvBcH4nd5KwVsDoA9NXspSmraFoccctc0cG4JHf7IfDH/IRu
pjqVaCIdnaJR42Jupwld9+0H2qCr0X1tvb0Av5WlRHWHCfg9NGDf631izEsEcIue
769dNd4+vK5Tll1mQyCoO6UkBopTFP9ug7jFygSkFZWgAjjzPwRRbGs/uTDq4bTW
21DF3SLrmeIBnJBUJrknT5k+CyddW7nO7tOrZbWpEUBYHfLqrig=
=QDEB
-----END PGP SIGNATURE-----

B
B
Brett Gilio wrote on 9 Dec 2019 19:33
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87fthtuz6n.fsf@posteo.net
Tobias Geerinckx-Rice <me@tobias.gr> writes:

Toggle quote (5 lines)
> 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

Toggle snippet (3 lines)
#:configure-flags (list "--enable-shared")

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

Toggle snippet (4 lines)
Building the following 1261 packages would ensure 3512 dependent
packages are rebuilt:

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
B
B
Brett Gilio wrote on 9 Dec 2019 21:57
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87tv69tdwz.fsf@posteo.net
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
B
B
Brett Gilio wrote on 13 Dec 2019 04:51
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87k170289b.fsf@posteo.net
Pushed to core-updates with fd248cb815d571043c3a0c52a01c9b3e368a069e.

Closing

--
Brett M. Gilio
Homepage -- https://scm.pw/
Closed
?