bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz <Stromeko@nexgo.de>]

Eli Zaretskii writes:
> What do you mean by "system libraries" here?  Does it, for example,
> include the DLLs distributed in the Cygwin port of libpng or libjpeg?
> Or does that include only the basic libraries: the Cygwin DLL, the C
> runtime, etc.?

Any and all dynamic objects that have been properly installed by the
Cygwin setup application will have their base addresses adjusted so that
there will be no overlapping images.  The rebase process tries to keep
this space reasonably compact, if you really need to have the most
compact address space you can trigger a full rebase.

> If the only problem is with non-preloaded *.eln files, why not rebase
> them on the fly, when they are loaded.  That is, run the 'rebase'
> command from the native-elisp-load function, before it actually loads
> the file.  User libraries are never loaded during startup, only when
> some Lisp requires them.

That might work.

>> ...but it wouldn't eliminate the need for rebasing at each start for the reasons 
>> explained above.
>
> Perhaps that need could be eliminated after all, see above.

The rebase would just happen at a different time, but I think it should
be OK.

> That's tough on users, because Emacs by default automatically compiles
> every .el file it loads into .eln, if there's no up-to-date .eln file
> already, and the compilation runs in the background (by forking
> additional Emacs sub-processes that run in batch mode).  In addition,
> the native-compilation process sometimes decides that it needs to
> create a special "trampoline" .eln file (if you want to know why, I'm
> sure Andrea can explain) that correspond to parts of the *.el files.
> The upshot is that users may not even be aware that new *.eln files
> have been created as part of their session, and may not know their
> names.  Unless the automatic rebase process, which runs from
> native-elisp-load, will also update the file in dynpath.d, I don't see
> how users could maintain such a database by hand in practice.

That's why Ken wants to ensure that the rebase is done directly after
the creation of such files.  We still need to rebase them again when the
system address map changes.

> There's one more aspect that you should be aware of.  A single file
> FOO.el could give birth to several different .eln files, for example
> if they are compiled by different Emacs binaries and/or from different
> source directories and/or from somewhat different versions of FOO.el.
> For example, I now have 3 different versions of .eln files
> corresponding to window.el, in the same directory:
>
>    window-0d1b8b93-3370bedb.eln
>    window-0d1b8b93-7d08b7b4.eln
>    window-0d1b8b93-f8fc9683.eln
>
> This makes the job of maintaining the database by hand even harder and
> more error-prone.

I have been wondering about that, especially since the user might have
the same home directory on different machines.  That will be a major
headache since we'll either need to find out which object belongs to
which system (and have separate maps for each) or somehow ensure that
the user rebase map is compatible with all systems the user works on.
Skipping that part for now, all such objects must be the same
architecture (i686-pc-cygwin / x86_64-pc-cygwin) and there should be
some sort of architecture specific branches in the cache directory,
which I seem to remember was already the case.  Rebasing would then just
treat every file in the current architecture branch as a separate object
(and use up address space for each).  Aside from the unfortunate
proliferation of objects files (which each use up space in 64kByte
blocks) it should still work however as long as there is never an object
with the same name but different content.  Trying to figure out which of
these can actually be used in the same process would be too much and
mostly wasted effort I'd think.

> My point is that maybe we should make that decision already, before
> burning too much time and energy on it.  Maybe you should ask on the
> Cygwin list whether somebody will object to making 32-bit Cygwin Emacs
> a second-class citizen.

We have not yet seen how well (or not) it works in practise, so I would
not make that call today.  Besides, there really is no way of knowing
ahead of time what users actually do and I would not like to take that
option away when just a small subset of users would run into trouble.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables