From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vicente Eduardo Subject: bug#38500: Ruby is built against libruby-static.a Date: Sun, 8 Dec 2019 15:44:09 +0100 Message-ID: References: <87fthwdr0p.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007e396b05993250bc" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42667) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idxo0-0002Em-FS for bug-guix@gnu.org; Sun, 08 Dec 2019 09:45:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idxny-0004Uo-B8 for bug-guix@gnu.org; Sun, 08 Dec 2019 09:45:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:44701) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1idxny-0004TF-4A for bug-guix@gnu.org; Sun, 08 Dec 2019 09:45:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1idxny-0006AF-0A for bug-guix@gnu.org; Sun, 08 Dec 2019 09:45:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87fthwdr0p.fsf@posteo.net> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Brett Gilio Cc: 38500@debbugs.gnu.org --0000000000007e396b05993250bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A1b., 7 dic. 2019 17:44, Brett Gilio escribi=C3= =B3: > Vicente Eduardo 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/ > --0000000000007e396b05993250bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Python and Ruby link dynamically by default from the exec= utable 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 exceptio= n of NodeJS which avoids this because of a design decision related to the d= istribution, and because it hasn't got an embedding API and an stable e= xtension API (N-API) until 8.x, and Rust, due to lack of ABI stability.
I didn't check GHC and Java y= et, 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=C2=A0 check the co= nfigure/Makefile of Ruby in order to see what flags do it need to compile a= gainst the dynamic library, and providing the static too as Debian distribu= tion does for Ruby (or Guix itself for Python and libpython3.7m.so).
El s=C3=A1b., 7 dic. 2019 17:44, Bre= tt Gilio <brettg@posteo.net>= escribi=C3=B3:
Vicente Eduardo <= ;v= ic798@gmail.com> writes:

> I would like to have two versions, or at least the dynamic one, that&#= 39;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/
--0000000000007e396b05993250bc--