unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Lausch <mick.lausch@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 70342@debbugs.gnu.org
Subject: bug#70342: 29.3.50; treesitter and RTLD_GLOBAL
Date: Thu, 11 Apr 2024 21:04:55 +0200	[thread overview]
Message-ID: <CAMDrkBfCgxYjBvhan8tHDogJhYgsv42toPOFwZNp0msh2oFf5Q@mail.gmail.com> (raw)
In-Reply-To: <86il0nu3v4.fsf@gnu.org>

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

On Thu, Apr 11, 2024 at 8:54 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Lausch <mick.lausch@gmail.com>
> > Date: Thu, 11 Apr 2024 20:47:50 +0200
> > Cc: 70342@debbugs.gnu.org
> >
> >  > A solution can be:
> >  > 1) use a special call to dlopen without the RTLD_OPEN flag, sim,ilar
> to what the eln loader does.
> >  > 2) fix all the grammars and make all functions 'static' so that the
> functions are not visible outside the
> >  > compilation unit.
> >  > 3) something i didn't think about
> >
> >  If those 'serialize' functions are not needed to be called from
> >  outside of the shared library, the usual way is not to export them,
> >  i.e. to give all symbols except the few that need to be exported the
> >  so-called "hidden visibility".
> >
> > I agree that this would be the cleanest way to solve the problem, but
> that would mean to patch all the existing
> > grammars and maybe all the future grammars and push the changes to their
> maintainers.
> >
> > I started to prep patches for the yaml and org grammar (those were the
> ones which triggered the bug for me)
> > and i'm going to have them merged upstream.
>
> I understand, but why is this an Emacs problem?  We use RTLD_GLOBAL
> for a reason, and the problem of not exposing unnecessary symbols
> should be solved by the respective libraries and those who build them.
>

You are completely right, the thing is that it may take a long time to fix
all the grammars and in the meantime,
whenever someone loads two buggy grammars in the same emacs process, it
will crash emacs. And that
causes more bug reports against emacs, even if it isn't an emacs problem.

The addition of yet another dlopen() function may mitigate this, but i
think that would lead to not fixing
the grammars, because it then works.

Therefore i created a bug, instead submitting a patch.

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

      reply	other threads:[~2024-04-11 19:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11 17:38 bug#70342: 29.3.50; treesitter and RTLD_GLOBAL Michael Lausch
2024-04-11 18:39 ` Eli Zaretskii
2024-04-11 18:47   ` Michael Lausch
2024-04-11 18:54     ` Eli Zaretskii
2024-04-11 19:04       ` Michael Lausch [this message]

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMDrkBfCgxYjBvhan8tHDogJhYgsv42toPOFwZNp0msh2oFf5Q@mail.gmail.com \
    --to=mick.lausch@gmail.com \
    --cc=70342@debbugs.gnu.org \
    --cc=eliz@gnu.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).