bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii <eliz@gnu.org>]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 23 Sep 2021 19:27:56 +0200
> 
> 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.

Out of curiosity, what do you do with the myriad DLLs that Windows
itself provides?  Aren't they part of the same problem with the Cygwin
implementation of 'fork'?

> >    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.

No, there are no architecture-specific branches.  I guess the idea is
that the 2 hashes in the file name and the 3rd has in the directory
name (which depends on the Emacs binary) will take care of that.