emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging MPS a.k.a. scratch/igc, yet again


From: Pip Cet
Subject: Re: Merging MPS a.k.a. scratch/igc, yet again
Date: Tue, 10 Dec 2024 15:10:44 +0000

On Tuesday, December 10th, 2024 at 13:10, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Xiyue Deng manphiz@gmail.com writes:
> * It is very likely that we end doing some patching to the MPS sources
> to adapt to our specific needs (if those patches end upstream or not,
> that's another question.)

If that ends up being the case, we'll have to make sure not to use shared 
libraries which may contain the upstream code. But that's true of all 
libraries; in the particular case of a Debian package, both the APT versioning 
schemes and ELF versioning are available for that.

> * MPS does a performance-critical job. Using it as a shared object might
> incur in a performance penalty. Having it in source form alongside the
> Emacs sources will result in opportunities for optimizations (LTO,
> PGO, ...) that may bring better performance.

...and more problems. MPS has made the decision not to work with gcc -O3, only 
with -O2 or less, and LTO in particular is something MPS cannot reliably 
support, IIUC.

> * MPS does a correctness-critical job. Depending on multiple external
> sources for such core component is a recipe for problems (future
> changes by the MPS maintainers, patching by packagers, buggy
> compilers, etc.) We need to keep a close watch on what MPS incarnation
> we use. Better yet, total control.

I think the correctness argument goes both ways: shared linking means bugs may 
be fixed for you automatically, as is routinely the case with libc.

> For those reasons, incorporating MPS into the Emacs sources is the right
> thing to do.

I don't think that's an option, because Emacs should remain capable of 
switching to GPLv4 if and when that is released, and we don't know whether the 
MPS license is compatible with such a future document.

So it's either static or dynamic linking; static links have these disadvantages:

* shared libraries on GNU/Linux have versioning, static libs don't, AFAIK
* legally, statically-linked binaries are quite different from 
dynamically-linked ones
* someone might enable LTO and break MPS (this may be done automatically by the 
compiler rather than a user error)
* with dynamic linking, there is some hope we could switch from libmps.so to 
libmps-debug.so without having to recompile Emacs, which would help us diagnose 
crashes in their actual environment

Pip



reply via email to

[Prev in Thread] Current Thread [Next in Thread]