GNU bug report logs - #70438
Emacs error 6 abort when starting rust-ts-mode

Previous Next

Full log

Message #45 received at 70438 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70438 <at> debbugs.gnu.org, Stefan Heitmann <sh <at> bytekomplex.de>
Subject: Re: bug#70438: Emacs error 6 abort when starting rust-ts-mode
Date: Fri, 26 Apr 2024 09:49:01 -0700

> On Apr 25, 2024, at 6:19 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Stefan Heitmann <sh <at> bytekomplex.de>
>> CC: "70438 <at> debbugs.gnu.org" <70438 <at> debbugs.gnu.org>
>> Date: Thu, 25 Apr 2024 11:24:13 +0000
>> 
>> Thank you very much for your help...
>> 
>> I think I understand roughly the issue and it makes sense that you can't do anything here... But I think, I could file another bug report for the repo maintainer of the arch package 😉
> 
> Yes, please.

In the GitHub issue that tracks this incident, the author made clear that maintaining ABI versioning correctly is beyond their ability right now. So I think we should pin the tree-sitter version. But then IIUC we can only bump tree-sitter version with each Emacs release? This is a bit unfortunate but better than crashing Emacs.

This also brings me to the versioning of tree-sitter grammars—they really do change often, we should really consider pinning their version in some way. The current catch-up game we play can’t be scalable.

Yuan

Quote:

>> Just so that this is clear to me: The solution to the immediate problem would be for the relevant Linux distros to issue a new Emacs package?

> I really think that in order to provide a reliable end-user experience, and prevent issue like this, Emacs should just statically link a particular version of Tree-sitter.

> If some Linux distros mandates that all libraries, no matter how small, must be distributed as dynamic libraries (which is just... staggeringly impractical IMO), then the Emacs package should specify a particular version of the Tree-sitter package to use - not a version range.

>> I think we have to commit to not using the semver version in our library names, and to follow libtool-compatible rules for selecting a SONAME instead.
>> 
> I agree with this. Ideally, we should set up tooling to automatically bump the soname on breaking ABI changes. But if any Emacs package maintainer is seeing this issue - we do not yet have this tooling - this library is maintained by a small team, and may not have perfect ABI stability! Consider taking a more conservative approach to dependency versioning, so that end users don't have to deal with situations like this!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.