From: Vicente Eduardo <vic798@gmail.com>
To: Brett Gilio <brettg@posteo.net>
Cc: 38500@debbugs.gnu.org
Subject: bug#38500: Ruby is built against libruby-static.a
Date: Sun, 8 Dec 2019 15:44:09 +0100 [thread overview]
Message-ID: <CAOUKKgHKMFhy-S6Xyo7XwLPQwoHkXD=TbeCTV3E6yjEF0R_2oA@mail.gmail.com> (raw)
In-Reply-To: <87fthwdr0p.fsf@posteo.net>
[-- 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 --]
next prev parent reply other threads:[~2019-12-08 14:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 13:25 bug#38500: Ruby is built against libruby-static.a Vicente Eduardo
2019-12-07 16:44 ` Brett Gilio
2019-12-08 14:44 ` Vicente Eduardo [this message]
2019-12-08 14:49 ` Vicente Eduardo
2019-12-08 15:42 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2019-12-09 18:33 ` Brett Gilio
2019-12-09 20:57 ` Brett Gilio
2019-12-13 3:51 ` Brett Gilio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOUKKgHKMFhy-S6Xyo7XwLPQwoHkXD=TbeCTV3E6yjEF0R_2oA@mail.gmail.com' \
--to=vic798@gmail.com \
--cc=38500@debbugs.gnu.org \
--cc=brettg@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.