[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
- Re: pdumper on Solaris 10, (continued)
- Re: pdumper on Solaris 10, Stefan Kangas, 2024/12/08
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/09
- Merging MPS a.k.a. scratch/igc, yet again, Stefan Kangas, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, chad, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Xiyue Deng, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Sean Whitton, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, chad, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again,
Pip Cet <=
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Pip Cet, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/10
- Re: Merging MPS a.k.a. scratch/igc, yet again, Xiyue Deng, 2024/12/11
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gregor Zattler, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Pip Cet, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gerd Möllmann, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Eli Zaretskii, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Gerd Möllmann, 2024/12/19
- Re: Merging MPS a.k.a. scratch/igc, yet again, Pip Cet, 2024/12/19