From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: lua upgrade plan
Date: Sun, 2 Jul 2017 03:55:54 +0000 (UTC) [thread overview]
Message-ID: <pan$c3699$1e4a2653$746c0ce9$2cddf9d1@cox.net> (raw)
In-Reply-To: 20170701165359.GB13095@linux1.home
William Hubbs posted on Sat, 01 Jul 2017 11:53:59 -0500 as excerpted:
> See this article for why using liblua as a shared library is not
> recommended.
>
> http://article.gmane.org/gmane.comp.lang.lua.general/18519
>
> Yes, it talks about the interpretor, but it goes further and really
> discourages even making a shared library available.
PMFJI, but...
That reply is from 2005 and is apparently specific to (32-bit) x86's
extreme shortage of general purpose registers. Back then it made sense
as 32-bit x86 was the dominant arch, both for gentoo, and (apparently)
for that lua discussion (which was in the debian context).
That x86 general lack of registers was one of the big pressures behind
the switch to amd64, before system memory sizes increased to 4GB+, and
applies far less to today's dominant amd64, with x86 now legacy/embedded.
Now it may well be that lua performance remains register sensitive even
with the increased number of registers available in amd64 and other
modern archs, but quoting an 11+-year-old email written in the extremely
register-restricted 32-bit x86 context does little to argue that point.
So... got any equivalent links to posts with more modern figures?
All that said, in FLOSS, he who volunteers, makes the rules, and
particularly given the upstream opposition meaning more gentoo-level work
required, if there's nobody willing to support lua in gentoo with dynamic
linking...
... people unable or unwilling to volunteer to support their preferred
alternative get to live with one they don't like, whether that be
accepting what their existing distro provides even if it's not optimal,
switching to another, or supporting their own patches or builds apart
from gentoo.
At least gentoo makes the latter case relatively easy compared to some
distros. I did it with kde twice, when gentoo/kde wasn't supporting
builds without semantic-desktop. =:^)
And in this case it appears there's even someone already doing it and
making their work public via the lua overlay. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2017-07-02 3:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 17:16 [gentoo-dev] lua upgrade plan William Hubbs
2017-07-01 8:16 ` Azamat Hackimov
2017-07-01 12:18 ` Vadim A. Misbakh-Soloviov
2017-07-01 16:53 ` William Hubbs
2017-07-02 3:55 ` Duncan [this message]
2017-07-02 15:30 ` [gentoo-dev] " William Hubbs
2017-07-03 1:43 ` Duncan
2017-07-03 3:32 ` Andrew Savchenko
2017-07-03 12:08 ` Martin Vaeth
2017-07-02 20:12 ` [gentoo-dev] " Vadim A. Misbakh-Soloviov
2017-07-02 20:14 ` M. J. Everitt
2017-07-03 14:41 ` William Hubbs
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='pan$c3699$1e4a2653$746c0ce9$2cddf9d1@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox