bug#50666: 28.0.50; Fix native compilation on Cygwin

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

Building --with-native-compilation on 32-bit Cygwin currently fails with
errors like the following:

child_info_fork::abort: address space needed by
'simple-fab5b0cf-aaf18a4e.eln' (0x5910000) is already occupied

This happens because shared libraries (usually DLLs, but also *.eln
files in this case) often need to be rebased in order for Cygwin's fork
implementation to work.  See

   https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process-problems

for an explanation.  It's mostly an issue in the 32-bit case because of
the limited address space, but on rare occasions it can be a problem on
64-bit Cygwin also.

For shared libraries installed in standard places, Cygwin normally takes
care of the rebasing automatically.  But if libraries are created in the
course of a build and then used later in the build, an "ephemeral" rebase
might be necessary.  This is the case for the *.eln libraries produced
during the emacs build.

In a followup to this message, I'll submit a patch that does this
ephemeral rebase and fixes the build problem.

Note: The build will not actually be convenient to use on 32-bit Cygwin, because 
sooner or later the *.eln files in ~/.emacs.d/eln-cache will also need to be 
rebased.  I hope to address this in future patches.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

On 9/18/2021 4:46 PM, Ken Brown wrote:
> In a followup to this message, I'll submit a patch that does this
> ephemeral rebase and fixes the build problem.

Patch attached.

[-- Attachment #2: 0001-Fix-build-with-native-compilation-on-Cygwin.patch --]
[-- Type: text/plain, Size: 1320 bytes --]

From 3a655d37dea44876b1cbc624b4cf1813945f9f2e Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Sat, 18 Sep 2021 14:03:41 -0400
Subject: [PATCH] Fix build with native compilation on Cygwin

* src/Makefile.in (emacs$(EXEEXT)) [CYGWIN]: Rebase the *.eln
files after they are all created, to avoid fork problems later
in the build.  (Bug#50666)
---
 src/Makefile.in | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/Makefile.in b/src/Makefile.in
index 732cd8f099..bb69a65707 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -547,6 +547,8 @@ ${charscript}:
 
 ${lispintdir}/characters.elc: ${charscript:.el=.elc}
 
+SYSTEM_TYPE = @SYSTEM_TYPE@
+
 ## The dumped Emacs is as functional and more efficient than
 ## bootstrap-emacs, so we replace the latter with the former.
 ## Strictly speaking, emacs does not depend directly on all of $lisp,
@@ -555,6 +557,9 @@ ${lispintdir}/characters.elc: ${charscript:
 emacs$(EXEEXT): temacs$(EXEEXT) \
                 lisp.mk $(etc)/DOC $(lisp) \
                 $(lispsource)/international/charprop.el ${charsets}
+ifeq ($(SYSTEM_TYPE),cygwin)
+	find ${top_builddir} -name '*.eln' | rebase -v -O -T -
+endif
 ifeq ($(DUMPING),unexec)
 	LC_ALL=C $(RUN_TEMACS) -batch $(BUILD_DETAILS) -l loadup --temacs=dump
   ifneq ($(PAXCTL_dumped),)
-- 
2.33.0

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Ken Brown <kbrown@cornell.edu>
> Date: Sat, 18 Sep 2021 16:46:42 -0400
> 
> In a followup to this message, I'll submit a patch that does this
> ephemeral rebase and fixes the build problem.

Thanks.

> Note: The build will not actually be convenient to use on 32-bit Cygwin, because 
> sooner or later the *.eln files in ~/.emacs.d/eln-cache will also need to be 
> rebased.  I hope to address this in future patches.

Why would they need to be rebased, and why doesn't your solution
handle those *.eln files as well?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Ken Brown <kbrown@cornell.edu>
> Date: Sat, 18 Sep 2021 16:58:21 -0400
> 
> * src/Makefile.in (emacs$(EXEEXT)) [CYGWIN]: Rebase the *.eln
> files after they are all created, to avoid fork problems later
> in the build.  (Bug#50666)

Now I see why this doesn't include the *.eln files in
~/.emacs.d/eln-cache.  But this means that on Cygwin, the only
practical way of building Emacs with native-compilation is to compile
everything, i.e. use NATIVE_FULL_AOT, which is unfortunate, IMO.

Isn't there a way to rebase a DLL on the fly, when it is loaded?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Eli Zaretskii writes:
> Isn't there a way to rebase a DLL on the fly, when it is loaded?

There is (of course), but then there is no guarantee that you can do a
fork from the resulting memory image.  Which is exactly the problem that
fixing the base addresses of all DLL was intended to solve and has the
unfortunate side effect that you need to modify the on-disk
representation.  On 64bit, marking the eln as ASLR w/ high-entropy and
large address aware will probably work most of the time, but 32bit is
much more prone to collisions (in fact I did use a shell inside an X11
Emacs as my test case when I last unsuccessfully tried to make ASLR work
for Cygwin).


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: ASSI <Stromeko@nexgo.de>
> Cc: Ken Brown <kbrown@cornell.edu>,  50666@debbugs.gnu.org
> Date: Sun, 19 Sep 2021 09:00:46 +0200
> 
> Eli Zaretskii writes:
> > Isn't there a way to rebase a DLL on the fly, when it is loaded?
> 
> There is (of course), but then there is no guarantee that you can do a
> fork from the resulting memory image.  Which is exactly the problem that
> fixing the base addresses of all DLL was intended to solve and has the
> unfortunate side effect that you need to modify the on-disk
> representation.  On 64bit, marking the eln as ASLR w/ high-entropy and
> large address aware will probably work most of the time, but 32bit is
> much more prone to collisions (in fact I did use a shell inside an X11
> Emacs as my test case when I last unsuccessfully tried to make ASLR work
> for Cygwin).

So this basically means that native-compilation is unworkable for
32-bit Cygwin, right?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Eli Zaretskii writes:
>> There is (of course), but then there is no guarantee that you can do a
>> fork from the resulting memory image.  Which is exactly the problem that
>> fixing the base addresses of all DLL was intended to solve and has the
>> unfortunate side effect that you need to modify the on-disk
>> representation.  On 64bit, marking the eln as ASLR w/ high-entropy and
>> large address aware will probably work most of the time, but 32bit is
>> much more prone to collisions (in fact I did use a shell inside an X11
>> Emacs as my test case when I last unsuccessfully tried to make ASLR work
>> for Cygwin).
>
> So this basically means that native-compilation is unworkable for
> 32-bit Cygwin, right?

Explicit rebasing should work on both architectures, the question is
just how to best ensure it's done correctly.


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

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: ASSI <Stromeko@nexgo.de>
> Cc: ASSI <Stromeko@nexgo.de>,  50666@debbugs.gnu.org
> Date: Sun, 19 Sep 2021 13:31:09 +0200
> 
> Eli Zaretskii writes:
> > So this basically means that native-compilation is unworkable for
> > 32-bit Cygwin, right?
> 
> Explicit rebasing should work on both architectures, the question is
> just how to best ensure it's done correctly.

Since Emacs 28 performs native-compilation automatically in the
background, and also automatically loads the *.eln files once
produced, I'm not sure what you mean by "should work" if we assume the
user will have to rebase manually.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/19/2021 8:06 AM, Eli Zaretskii wrote:
>> From: ASSI <Stromeko@nexgo.de>
>> Cc: ASSI <Stromeko@nexgo.de>,  50666@debbugs.gnu.org
>> Date: Sun, 19 Sep 2021 13:31:09 +0200
>>
>> Eli Zaretskii writes:
>>> So this basically means that native-compilation is unworkable for
>>> 32-bit Cygwin, right?
>>
>> Explicit rebasing should work on both architectures, the question is
>> just how to best ensure it's done correctly.
> 
> Since Emacs 28 performs native-compilation automatically in the
> background, and also automatically loads the *.eln files once
> produced, I'm not sure what you mean by "should work" if we assume the
> user will have to rebase manually.

Cygwin could maintain a per-user database of *.eln files and their base 
addresses.  (It already maintains a system database of this type.)  The each 
time a new *.eln file is created, it could be rebased and added to the database 
before being loaded.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 19 Sep 2021 08:37:52 -0400
> 
> Cygwin could maintain a per-user database of *.eln files and their base 
> addresses.  (It already maintains a system database of this type.)  The each 
> time a new *.eln file is created, it could be rebased and added to the database 
> before being loaded.

I don't think I understand: rebased and added how? manually?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/19/2021 9:41 AM, Eli Zaretskii wrote:
>> Cc: 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 19 Sep 2021 08:37:52 -0400
>>
>> Cygwin could maintain a per-user database of *.eln files and their base
>> addresses.  (It already maintains a system database of this type.)  The each
>> time a new *.eln file is created, it could be rebased and added to the database
>> before being loaded.
> 
> I don't think I understand: rebased and added how? manually?

No, by a script that Cygwin would have to create and that Emacs would call.  We 
already have scripts that do system-wide rebasing (and that are run 
automatically, without user intervention).  The question would be how to extend 
this to per-user rebasing.  Achim and I have just begun discussing this on the 
Cygwin mailing lists (currently the cygwin-apps list).  I think it's doable with 
some effort.

In the meantime, is it OK if I install my patch to enable building with native 
compilation?  That would simplify experimentation.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 19 Sep 2021 10:27:27 -0400
> 
> > I don't think I understand: rebased and added how? manually?
> 
> No, by a script that Cygwin would have to create and that Emacs would call.  We 
> already have scripts that do system-wide rebasing (and that are run 
> automatically, without user intervention).  The question would be how to extend 
> this to per-user rebasing.  Achim and I have just begun discussing this on the 
> Cygwin mailing lists (currently the cygwin-apps list).  I think it's doable with 
> some effort.
> 
> In the meantime, is it OK if I install my patch to enable building with native 
> compilation?  That would simplify experimentation.

Yes, it's okay to install that, but it's a band-aid at best, and we'd
like to have the complete solution in Emacs before we release v28.1.
Is that feasible?

Thanks.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/19/2021 11:28 AM, Eli Zaretskii wrote:
>> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 19 Sep 2021 10:27:27 -0400
>>
>>> I don't think I understand: rebased and added how? manually?
>>
>> No, by a script that Cygwin would have to create and that Emacs would call.  We
>> already have scripts that do system-wide rebasing (and that are run
>> automatically, without user intervention).  The question would be how to extend
>> this to per-user rebasing.  Achim and I have just begun discussing this on the
>> Cygwin mailing lists (currently the cygwin-apps list).  I think it's doable with
>> some effort.
>>
>> In the meantime, is it OK if I install my patch to enable building with native
>> compilation?  That would simplify experimentation.
> 
> Yes, it's okay to install that, but it's a band-aid at best, and we'd
> like to have the complete solution in Emacs before we release v28.1.
> Is that feasible?

Yes, I think so.  And if we're not able to do it, I would propose disabling 
native compilation on 32-bit Cygwin.  The user experience is terrible as it stands.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 19 Sep 2021 12:17:51 -0400
> 
> >> In the meantime, is it OK if I install my patch to enable building with native
> >> compilation?  That would simplify experimentation.
> > 
> > Yes, it's okay to install that, but it's a band-aid at best, and we'd
> > like to have the complete solution in Emacs before we release v28.1.
> > Is that feasible?
> 
> Yes, I think so.

Great, let's hopw you will succeed.

> And if we're not able to do it, I would propose disabling native
> compilation on 32-bit Cygwin.  The user experience is terrible as it
> stands.

Yes, that's why I said "unworkable".  Indeed, disabling it in that
case would be TRT.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/19/2021 1:12 PM, Eli Zaretskii wrote:
>> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 19 Sep 2021 12:17:51 -0400
>>
>>>> In the meantime, is it OK if I install my patch to enable building with native
>>>> compilation?  That would simplify experimentation.
>>>
>>> Yes, it's okay to install that, but it's a band-aid at best, and we'd
>>> like to have the complete solution in Emacs before we release v28.1.
>>> Is that feasible?
>>
>> Yes, I think so.
> 
> Great, let's hopw you will succeed.

We've made a good start on the Cygwin side, but I have a question about how to 
integrate it into Emacs.

Let's say we have a script that I'll call "rebase" for the purpose of this 
discussion, which rebases all the eln files in ~/.emacs.d/eln-cache.  The user 
would then start Emacs via a script that first calls rebase and then starts 
Emacs.  Within Emacs, I would then want to do something like

(if (eq system-type 'cygwin)
     (call-process "rebase" nil
                   '(:file "<log file>")
                   nil "<arg>" ...))

after every compilation but before the compiled file is loaded.

I'm not familiar enough with native compilation to know where this should go. 
Or maybe it has to be done in more than one place, depending on whether the 
compilation is synchronous or not.

Can you help?

Thanks.

Ken

P.S. The rebase script will fail to rebase eln files that are already loaded, 
but that's harmless in the scenario above.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Wed, 22 Sep 2021 17:35:28 -0400
> 
> We've made a good start on the Cygwin side, but I have a question about how to 
> integrate it into Emacs.

I added Andrea to this discussion, as he knows more than anyone else
about the Emacs side of this stuff.

> Let's say we have a script that I'll call "rebase" for the purpose of this 
> discussion, which rebases all the eln files in ~/.emacs.d/eln-cache.  The user 
> would then start Emacs via a script that first calls rebase and then starts 
> Emacs.

Is it really necessary to rebase the *.eln files before each startup?
Isn't it enough to rebase each of the .eln files just once, when it is
produced?  If indeed this is needed every time, can you explain why?

> Within Emacs, I would then want to do something like
> 
> (if (eq system-type 'cygwin)
>      (call-process "rebase" nil
>                    '(:file "<log file>")
>                    nil "<arg>" ...))
> 
> after every compilation but before the compiled file is loaded.
> 
> I'm not familiar enough with native compilation to know where this should go. 

The non-preloaded *.eln files are all loaded by native-elisp-load, so
I guess the rebase should be launched from there?  The preloaded *.eln
files are loaded in pdumper.c:dump_do_dump_relocation, but do we need
to support non-rebased preloaded *.eln files?

> Or maybe it has to be done in more than one place, depending on whether the 
> compilation is synchronous or not.
> 
> Can you help?

I hope the above helps.  But I think we should understand better all
the aspects of this issue, to make sure it will work correctly in the
wild.  The *.eln files bring quite a few new and unusual aspects and
dependencies to Emacs, they are not just another kind of DLLs loaded
dynamically.  So I'd appreciate if you explained:

  . why is rebasing needed (I think I understand that part, but I'd
    prefer an explanation from the experts)
  . how will the 'rebase' utility determine to which address to remap
    each .eln file

> P.S. The rebase script will fail to rebase eln files that are already loaded, 
> but that's harmless in the scenario above.

When an updated .eln file is produced for .eln that is loaded into
some running Emacs, Emacs on Windows renames the original .eln to
avoid a similar problem.  Can't you use the same technique, to avoid
the need of rebasing on each start?  Please note that users could
place *.eln files in unusual locations (and customize
native-comp-eln-load-path to reflect that), so finding _all_ of the
relevant *.eln files from a shell script might not be easy.  In fact,
even without customizing the load-path, I don't think I understand how
will that script you propose know where to find all the *.eln files.

Thanks.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/23/2021 3:42 AM, Eli Zaretskii wrote:
>> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Wed, 22 Sep 2021 17:35:28 -0400
>>
>> We've made a good start on the Cygwin side, but I have a question about how to
>> integrate it into Emacs.
> 
> I added Andrea to this discussion, as he knows more than anyone else
> about the Emacs side of this stuff.
> 
>> Let's say we have a script that I'll call "rebase" for the purpose of this
>> discussion, which rebases all the eln files in ~/.emacs.d/eln-cache.  The user
>> would then start Emacs via a script that first calls rebase and then starts
>> Emacs.
> 
> Is it really necessary to rebase the *.eln files before each startup?
> Isn't it enough to rebase each of the .eln files just once, when it is
> produced?  If indeed this is needed every time, can you explain why?

We have to distinguish between system libraries and user libraries.  Libraries 
installed by Cygwin packages are system libraries.  The *.eln files in 
~/.emacs.d/eln-cache are user libraries.  Cygwin maintains a database of all 
system libraries and their base addresses.  Whenever a Cygwin package is 
installed or updated, Cygwin rebases all system libraries and updates the database.

Each time Emacs starts, it has no way of knowing whether the system libraries 
have been rebased since the last time Emacs was run.  So the user's *.eln files 
could now have base address conflicts with system libraries.  Rebasing the *.eln 
files fixes this problem.

>> Within Emacs, I would then want to do something like
>>
>> (if (eq system-type 'cygwin)
>>       (call-process "rebase" nil
>>                     '(:file "<log file>")
>>                     nil "<arg>" ...))
>>
>> after every compilation but before the compiled file is loaded.
>>
>> I'm not familiar enough with native compilation to know where this should go.
> 
> The non-preloaded *.eln files are all loaded by native-elisp-load, so
> I guess the rebase should be launched from there?  The preloaded *.eln
> files are loaded in pdumper.c:dump_do_dump_relocation, but do we need
> to support non-rebased preloaded *.eln files?

The preloaded *.eln files will be installed by Cygwin's package manager when 
emacs is installed.  They are therefore system libraries and are automatically 
rebased as needed.

>> Can you help?
> 
> I hope the above helps.  But I think we should understand better all
> the aspects of this issue, to make sure it will work correctly in the
> wild.  The *.eln files bring quite a few new and unusual aspects and
> dependencies to Emacs, they are not just another kind of DLLs loaded
> dynamically.  So I'd appreciate if you explained:
> 
>    . why is rebasing needed (I think I understand that part, but I'd
>      prefer an explanation from the experts)

I'm not as expert as I'd like to be on the intricacies of Cygwin's fork 
implementation, but here's my best attempt.  Achim may want to correct it or add 
to it.

When Cygwin forks, it creates a new process and copies the memory image of the 
parent to the child.  But Cygwin uses the Windows loader to load DLLs, so it has 
to ensure that Windows will load all DLLs to the same addresses in the child at 
which they were loaded in the parent.

The problem occurs when there's an address collision, i.e., two DLLs have the 
same hard-wired base address.  Window then resolves the collision by loading one 
of them at a different address.  But there's no guarantee that it will resolve 
the collision in the child the same way it resolved it in the parent.  That 
leads to a fork failure.

Cygwin tries to head-off such problems before they occur by rebasing as I've 
described above at package-installation time.

>    . how will the 'rebase' utility determine to which address to remap
>      each .eln file

It simply chooses an address that doesn't conflict with any of the system 
libraries and the already-rebased user libraries.

>> P.S. The rebase script will fail to rebase eln files that are already loaded,
>> but that's harmless in the scenario above.
> 
> When an updated .eln file is produced for .eln that is loaded into
> some running Emacs, Emacs on Windows renames the original .eln to
> avoid a similar problem.  

I hadn't thought of this issue.  We may have to use a similar technique...

> Can't you use the same technique, to avoid
> the need of rebasing on each start?

...but it wouldn't eliminate the need for rebasing at each start for the reasons 
explained above.

>  Please note that users could
> place *.eln files in unusual locations (and customize
> native-comp-eln-load-path to reflect that), so finding _all_ of the
> relevant *.eln files from a shell script might not be easy.  In fact,
> even without customizing the load-path, I don't think I understand how
> will that script you propose know where to find all the *.eln files.

The current proposal that Achim and I are looking at would require each user to 
maintain a file ~/.config/rebase/dynpath.d/emacs containing a list of 
directories where the .eln files can be found.  By default, this file would 
contain one line, which is the path to the standard eln-cache directory.  Users 
who customize native-comp-eln-load-path would have to modify that file accordingly.

For example, I currently have a second line pointing to the native-lisp 
directory of my emacs build directory, so that I can do testing of my built 
emacs without having to install it.

Finally, as a side note, I don't think it would be a tragedy if this just turns 
out to be too complicated and we have to disable native compilation on 32-bit 
Cygwin.  The Cygwin home page at https://cygwin.com/ already contains the following:

   Address space is a very limiting factor for Cygwin. These days, a full
   32 bit Cygwin distro is not feasible anymore, and will in all likelihood
   fail in random places due to an issue with the fork(2) system call.

   Therefore we recommend using 32 bit Cygwin only in limited scenarios, with
   only a minimum of necessary packages installed, and only if there's no way
   to run 64 bit Cygwin instead.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Thu, 23 Sep 2021 10:20:19 -0400
> 
> > Is it really necessary to rebase the *.eln files before each startup?
> > Isn't it enough to rebase each of the .eln files just once, when it is
> > produced?  If indeed this is needed every time, can you explain why?
> 
> We have to distinguish between system libraries and user libraries.  Libraries 
> installed by Cygwin packages are system libraries.  The *.eln files in 
> ~/.emacs.d/eln-cache are user libraries.  Cygwin maintains a database of all 
> system libraries and their base addresses.  Whenever a Cygwin package is 
> installed or updated, Cygwin rebases all system libraries and updates the database.
> 
> Each time Emacs starts, it has no way of knowing whether the system libraries 
> have been rebased since the last time Emacs was run.  So the user's *.eln files 
> could now have base address conflicts with system libraries.  Rebasing the *.eln 
> files fixes this problem.

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

> > The non-preloaded *.eln files are all loaded by native-elisp-load, so
> > I guess the rebase should be launched from there?  The preloaded *.eln
> > files are loaded in pdumper.c:dump_do_dump_relocation, but do we need
> > to support non-rebased preloaded *.eln files?
> 
> The preloaded *.eln files will be installed by Cygwin's package manager when 
> emacs is installed.  They are therefore system libraries and are automatically 
> rebased as needed.

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.

> > When an updated .eln file is produced for .eln that is loaded into
> > some running Emacs, Emacs on Windows renames the original .eln to
> > avoid a similar problem.  
> 
> I hadn't thought of this issue.  We may have to use a similar technique...
> 
> > Can't you use the same technique, to avoid
> > the need of rebasing on each start?
> 
> ...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.

> >  Please note that users could
> > place *.eln files in unusual locations (and customize
> > native-comp-eln-load-path to reflect that), so finding _all_ of the
> > relevant *.eln files from a shell script might not be easy.  In fact,
> > even without customizing the load-path, I don't think I understand how
> > will that script you propose know where to find all the *.eln files.
> 
> The current proposal that Achim and I are looking at would require each user to 
> maintain a file ~/.config/rebase/dynpath.d/emacs containing a list of 
> directories where the .eln files can be found.  By default, this file would 
> contain one line, which is the path to the standard eln-cache directory.  Users 
> who customize native-comp-eln-load-path would have to modify that file accordingly.

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.

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.

> Finally, as a side note, I don't think it would be a tragedy if this just turns 
> out to be too complicated and we have to disable native compilation on 32-bit 
> Cygwin.  The Cygwin home page at https://cygwin.com/ already contains the following:
> 
>    Address space is a very limiting factor for Cygwin. These days, a full
>    32 bit Cygwin distro is not feasible anymore, and will in all likelihood
>    fail in random places due to an issue with the fork(2) system call.
> 
>    Therefore we recommend using 32 bit Cygwin only in limited scenarios, with
>    only a minimum of necessary packages installed, and only if there's no way
>    to run 64 bit Cygwin instead.

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.

Thanks.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 9/23/2021 12:37 PM, Eli Zaretskii wrote:
>> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Thu, 23 Sep 2021 10:20:19 -0400
>>
>>> Is it really necessary to rebase the *.eln files before each startup?
>>> Isn't it enough to rebase each of the .eln files just once, when it is
>>> produced?  If indeed this is needed every time, can you explain why?
>>
>> We have to distinguish between system libraries and user libraries.  Libraries
>> installed by Cygwin packages are system libraries.  The *.eln files in
>> ~/.emacs.d/eln-cache are user libraries.  Cygwin maintains a database of all
>> system libraries and their base addresses.  Whenever a Cygwin package is
>> installed or updated, Cygwin rebases all system libraries and updates the database.
>>
>> Each time Emacs starts, it has no way of knowing whether the system libraries
>> have been rebased since the last time Emacs was run.  So the user's *.eln files
>> could now have base address conflicts with system libraries.  Rebasing the *.eln
>> files fixes this problem.
> 
> What do you mean by "system libraries" here?  Does it, for example,
> include the DLLs distributed in the Cygwin port of libpng or libjpeg?

Yes.

> Or does that include only the basic libraries: the Cygwin DLL, the C
> runtime, etc.? >
>>> The non-preloaded *.eln files are all loaded by native-elisp-load, so
>>> I guess the rebase should be launched from there?  The preloaded *.eln
>>> files are loaded in pdumper.c:dump_do_dump_relocation, but do we need
>>> to support non-rebased preloaded *.eln files?
>>
>> The preloaded *.eln files will be installed by Cygwin's package manager when
>> emacs is installed.  They are therefore system libraries and are automatically
>> rebased as needed.
> 
> 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.

Good idea.

>>> When an updated .eln file is produced for .eln that is loaded into
>>> some running Emacs, Emacs on Windows renames the original .eln to
>>> avoid a similar problem.
>>
>> I hadn't thought of this issue.  We may have to use a similar technique...
>>
>>> Can't you use the same technique, to avoid
>>> the need of rebasing on each start?
>>
>> ...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.
> 
>>>   Please note that users could
>>> place *.eln files in unusual locations (and customize
>>> native-comp-eln-load-path to reflect that), so finding _all_ of the
>>> relevant *.eln files from a shell script might not be easy.  In fact,
>>> even without customizing the load-path, I don't think I understand how
>>> will that script you propose know where to find all the *.eln files.
>>
>> The current proposal that Achim and I are looking at would require each user to
>> maintain a file ~/.config/rebase/dynpath.d/emacs containing a list of
>> directories where the .eln files can be found.  By default, this file would
>> contain one line, which is the path to the standard eln-cache directory.  Users
>> who customize native-comp-eln-load-path would have to modify that file accordingly.
> 
> 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.
> 
> 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.
> 
>> Finally, as a side note, I don't think it would be a tragedy if this just turns
>> out to be too complicated and we have to disable native compilation on 32-bit
>> Cygwin.  The Cygwin home page at https://cygwin.com/ already contains the following:
>>
>>     Address space is a very limiting factor for Cygwin. These days, a full
>>     32 bit Cygwin distro is not feasible anymore, and will in all likelihood
>>     fail in random places due to an issue with the fork(2) system call.
>>
>>     Therefore we recommend using 32 bit Cygwin only in limited scenarios, with
>>     only a minimum of necessary packages installed, and only if there's no way
>>     to run 64 bit Cygwin instead.
> 
> My point is that maybe we should make that decision already, before
> burning too much time and energy on it.

You might be right.  I wasn't aware of all the complications you mentioned above.

We still need to do something for 64-bit Cygwin.  Even though address collisions 
are unlikely they could still happen theoretically.  But there might be a much 
easier solution that doesn't necessarily require rebasing.  For example, Achim 
mentioned earlier the possibility of marking the eln as ASLR w/ high-entropy and
large address aware.

> Maybe you should ask on the
> Cygwin list whether somebody will object to making 32-bit Cygwin Emacs
> a second-class citizen.

Well, 32-bit Cygwin is already a second-class citizen, so we might just have to 
do that whether someone objects or not.  But I'll continue the discussion with 
Achim on the cygwin-apps list before making a final decision.

Thanks for all your comments and suggestions.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz]

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

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: akrl@sdf.org, Stromeko@nexgo.de, 50666@debbugs.gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> Date: Thu, 23 Sep 2021 13:13:05 -0400
> 
> > My point is that maybe we should make that decision already, before
> > burning too much time and energy on it.
> 
> You might be right.  I wasn't aware of all the complications you mentioned above.

It took us most of the last year to realize how tricky this stuff is.
We are still learning ;-)

> We still need to do something for 64-bit Cygwin.  Even though address collisions 
> are unlikely they could still happen theoretically.  But there might be a much 
> easier solution that doesn't necessarily require rebasing.  For example, Achim 
> mentioned earlier the possibility of marking the eln as ASLR w/ high-entropy and
> large address aware.

Isn't that the default of the 64-bit GNU ld on Windows?  Or does
Cygwin configure Binutils differently from MinGW?

If not, we can use native-comp-driver-options, by giving it a non-nil
value for Cygwin, to force this.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

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

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz]

Eli Zaretskii writes:
>> We still need to do something for 64-bit Cygwin.  Even though address collisions 
>> are unlikely they could still happen theoretically.  But there might be a much 
>> easier solution that doesn't necessarily require rebasing.  For example, Achim 
>> mentioned earlier the possibility of marking the eln as ASLR w/ high-entropy and
>> large address aware.
>
> Isn't that the default of the 64-bit GNU ld on Windows?  Or does
> Cygwin configure Binutils differently from MinGW?

No, I've had to remove that default since obviously it doesn't work on
Cygwin.  Yes, I have seen this problem in reality while testing the
new binutils - that why I patched it out.

> If not, we can use native-comp-driver-options, by giving it a non-nil
> value for Cygwin, to force this.

All that would be needed, on 64bit at least, is a tiny bit more control
over how ASLR works, but there isn't even proper documentation about
what it actually does (that I can find anyway).  M$ must have solved
that problem for WSL1, but whatever it was, it didn't make it to the NT
subsystem.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 23 Sep 2021 19:49:05 +0200
> 
> Eli Zaretskii writes:
> >> We still need to do something for 64-bit Cygwin.  Even though address collisions 
> >> are unlikely they could still happen theoretically.  But there might be a much 
> >> easier solution that doesn't necessarily require rebasing.  For example, Achim 
> >> mentioned earlier the possibility of marking the eln as ASLR w/ high-entropy and
> >> large address aware.
> >
> > Isn't that the default of the 64-bit GNU ld on Windows?  Or does
> > Cygwin configure Binutils differently from MinGW?
> 
> No, I've had to remove that default since obviously it doesn't work on
> Cygwin.

You mean, ASLR doesn't work with Cygwin because it must use the same
address in the forked process?  But then why did Ken say that ASLR and
High Entropy could solve the problem with the *.eln files -- isn't
that the same problem?

> > If not, we can use native-comp-driver-options, by giving it a non-nil
> > value for Cygwin, to force this.
> 
> All that would be needed, on 64bit at least, is a tiny bit more control
> over how ASLR works, but there isn't even proper documentation about
> what it actually does (that I can find anyway).  M$ must have solved
> that problem for WSL1, but whatever it was, it didn't make it to the NT
> subsystem.

Sorry, I don't understand.  My suggestion was, if you need to make the
*.eln files be marked as ASLR with High Entropy, to use a variable we
have for this purpose, it will force the linker to produce *.eln files
with these bits set in the PE+ header.  What other control do you need
for your purposes, or what am I missing?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz]

Eli Zaretskii writes:
> You mean, ASLR doesn't work with Cygwin because it must use the same
> address in the forked process?  But then why did Ken say that ASLR and
> High Entropy could solve the problem with the *.eln files -- isn't
> that the same problem?

It is, but on 64bit with the massive address space and high entropy
using most of it, it will often "just work" for quite some time.

> Sorry, I don't understand.  My suggestion was, if you need to make the
> *.eln files be marked as ASLR with High Entropy, to use a variable we
> have for this purpose, it will force the linker to produce *.eln files
> with these bits set in the PE+ header.  What other control do you need
> for your purposes, or what am I missing?

The control that Cygwin would need is an indication to whatever
generates the image base shifts for ASLR that it should not re-map an
image that is already in use elsewhere (maybe just in the same process
group).  ASLR already re-uses the address for the same image most of the
time (the exact behaviour is different across Windows versions), but
depending on circumstances outside your control it can suddenly decide
to use a different address.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz]

Eli Zaretskii writes:
> 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'?

These are never part of the Cygwin process.

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

Hmm, I seem to remember some post from Andrea that showed a
x86_64-pc-linux-gnu subdirectory for the cached files.  So how are these
hashes generated, then?


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 23 Sep 2021 20:25:02 +0200
> 
> Eli Zaretskii writes:
> > You mean, ASLR doesn't work with Cygwin because it must use the same
> > address in the forked process?  But then why did Ken say that ASLR and
> > High Entropy could solve the problem with the *.eln files -- isn't
> > that the same problem?
> 
> It is, but on 64bit with the massive address space and high entropy
> using most of it, it will often "just work" for quite some time.

I understand that it might "just work" wrt collisions, but what about
the requirement that the DLL be loaded at the same address in the
forked child?  Doesn't ASLR randomize the base address each time a DLL
is loaded?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 23 Sep 2021 20:29:45 +0200
> 
> > 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.
> 
> Hmm, I seem to remember some post from Andrea that showed a
> x86_64-pc-linux-gnu subdirectory for the cached files.  So how are these
> hashes generated, then?

The directory where the *.eln files are installed is named XX.YY-HASH,
where XX.YY is the Emacs version and HASH is computed by hashing the
string that's the concatenation of the native-compilation ABI version,
the Emacs version, the system-configuration (that's your
x86_64-pc-linux-gnu thing), system-configuration-options, and the
signatures of all the primitives.

The *.eln file names have 2 hashes: one is computed from the absolute
file name of the source .el file, the other from the contents of the
source .el file.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Wed, 22 Sep 2021 17:35:28 -0400
>> 
>> We've made a good start on the Cygwin side, but I have a question about how to 
>> integrate it into Emacs.
>
> I added Andrea to this discussion, as he knows more than anyone else
> about the Emacs side of this stuff.
>
>> Let's say we have a script that I'll call "rebase" for the purpose of this 
>> discussion, which rebases all the eln files in ~/.emacs.d/eln-cache.  The user 
>> would then start Emacs via a script that first calls rebase and then starts 
>> Emacs.
>
> Is it really necessary to rebase the *.eln files before each startup?
> Isn't it enough to rebase each of the .eln files just once, when it is
> produced?  If indeed this is needed every time, can you explain why?
>
>> Within Emacs, I would then want to do something like
>> 
>> (if (eq system-type 'cygwin)
>>      (call-process "rebase" nil
>>                    '(:file "<log file>")
>>                    nil "<arg>" ...))
>> 
>> after every compilation but before the compiled file is loaded.
>> 
>> I'm not familiar enough with native compilation to know where this should go. 
>
> The non-preloaded *.eln files are all loaded by native-elisp-load, so
> I guess the rebase should be launched from there?  The preloaded *.eln
> files are loaded in pdumper.c:dump_do_dump_relocation, but do we need
> to support non-rebased preloaded *.eln files?

Yes I think too `native-elisp-load' and `dump_do_dump_relocation' are
the two places we'd want to trigger the rebase (not sure if in
`dump_do_dump_relocation' we are already able to spawn subprocesses
tho).

That said I'm wondering what is going to happen if an Emacs is running
and a second sessions starts rebasing some eln.

  Andrea

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Ken Brown <kbrown@cornell.edu>, Stromeko@nexgo.de, 50666@debbugs.gnu.org
> Date: Thu, 23 Sep 2021 19:11:05 +0000
> 
> That said I'm wondering what is going to happen if an Emacs is running
> and a second sessions starts rebasing some eln.

I think the session which rebases will have to use the same trick with
renaming we use when recompiling a loaded .eln.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eli Zaretskii writes:
>> 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'?
>
> These are never part of the Cygwin process.
>
>> 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.
>
> Hmm, I seem to remember some post from Andrea that showed a
> x86_64-pc-linux-gnu subdirectory for the cached files.  So how are these
> hashes generated, then?

Hi Achim,

the triplet is not mentioned explicitly in the generated path as it was
deemed to be excessively verbose.  It is now included in the hash of the
directory name.

To get practical I've:

~/.emacs.d/eln-cache/28.0.50-2045295c/apropos-7c1ecbdf-10e46ddb.eln
                              ^^^               ^^^       ^^^
                               A                 B         C

A- accounts for emacs-verison, system-configuration,
   system-configuration-options and the signatures of all the subr
   present in the C code.

B- accounts for the absolute filename of
   the source file

C- accounts for the content for the source file

Regards

  Andrea

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" writes:
> That said I'm wondering what is going to happen if an Emacs is running
> and a second sessions starts rebasing some eln.

You can't rebase an object that is already loaded on Windows (or load an
object that is in the process of getting rebased), so I would not worry
about this situation too much at the moment.


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" writes:
> To get practical I've:
>
> ~/.emacs.d/eln-cache/28.0.50-2045295c/apropos-7c1ecbdf-10e46ddb.eln
>                               ^^^               ^^^       ^^^
>                                A                 B         C
>
> A- accounts for emacs-verison, system-configuration,
>    system-configuration-options and the signatures of all the subr
>    present in the C code.

OK, so this would be unique for one Cygwin Emacs release and architecture.

> B- accounts for the absolute filename of
>    the source file

In general, is this hardcoded or can we change the hashing strategy for
Cygwin via some configuration or hook?

> C- accounts for the content for the source file

Can you point me to the part of the discussion where it was determined
that the absolute location of the file was making a difference that was
not covered with the hash of the content?


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: ASSI <Stromeko@nexgo.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Andrea Corallo <akrl@sdf.org>,
>   Stromeko@nexgo.de,  50666@debbugs.gnu.org,  Ken Brown
>  <kbrown@cornell.edu>
> Date: Fri, 24 Sep 2021 08:04:09 +0200
> 
> You can't rebase an object that is already loaded on Windows (or load an
> object that is in the process of getting rebased), so I would not worry
> about this situation too much at the moment.

This means that the following situation will predictably fail:

  . Emacs session A (or just some shell command) rebases a .eln file
  . Emacs session B decides it needs to load that .eln

What kind of failure will session B see in this case?  Is it possible
to figure out somehow that this is the reason, so that we could
instead try loading the .elc or .el?

Or maybe we should add an automatic fallback on .elc/.el in case
loading a .eln fails?  Andrea, WDYT? will that work?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: ASSI <Stromeko@nexgo.de>
> Date: Fri, 24 Sep 2021 08:11:08 +0200
> Cc: Stromeko@nexgo.de, akrl@sdf.org
> 
> > B- accounts for the absolute filename of
> >    the source file
> 
> In general, is this hardcoded or can we change the hashing strategy for
> Cygwin via some configuration or hook?

It's currently hardcoded.  Why do you need to change it?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: ASSI <Stromeko@nexgo.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Andrea Corallo <akrl@sdf.org>,
>>   Stromeko@nexgo.de,  50666@debbugs.gnu.org,  Ken Brown
>>  <kbrown@cornell.edu>
>> Date: Fri, 24 Sep 2021 08:04:09 +0200
>> 
>> You can't rebase an object that is already loaded on Windows (or load an
>> object that is in the process of getting rebased), so I would not worry
>> about this situation too much at the moment.
>
> This means that the following situation will predictably fail:
>
>   . Emacs session A (or just some shell command) rebases a .eln file
>   . Emacs session B decides it needs to load that .eln
>
> What kind of failure will session B see in this case?  Is it possible
> to figure out somehow that this is the reason, so that we could
> instead try loading the .elc or .el?
>
> Or maybe we should add an automatic fallback on .elc/.el in case
> loading a .eln fails?  Andrea, WDYT? will that work?

Yes I think we could have an automatic fallback, we might have
'native-elisp-load' (invoked by 'load') re invoke load itself in case of
failure, not very clean tho.

But aside the fact that is implementable I think it should be limited to
just this specific load failure, otherwise it could easily mask other
issues.  And this raise another question: can we identify this specific
kind of load failure?

  Andrea

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

ASSI <Stromeko@nexgo.de> writes:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" writes:
>> To get practical I've:
>>
>> ~/.emacs.d/eln-cache/28.0.50-2045295c/apropos-7c1ecbdf-10e46ddb.eln
>>                               ^^^               ^^^       ^^^
>>                                A                 B         C
>>
>> A- accounts for emacs-verison, system-configuration,
>>    system-configuration-options and the signatures of all the subr
>>    present in the C code.
>
> OK, so this would be unique for one Cygwin Emacs release and architecture.
>
>> B- accounts for the absolute filename of
>>    the source file
>
> In general, is this hardcoded or can we change the hashing strategy for
> Cygwin via some configuration or hook?

Hardcoded. Could you explain why this could be problematic for cygwin?

>> C- accounts for the content for the source file
>
> Can you point me to the part of the discussion where it was determined
> that the absolute location of the file was making a difference that was
> not covered with the hash of the content?

Not at the moment sorry, this was discussed more the once in different
threads in the last 1-2 years.

Note we use the absolute location hash mainly to try to keep clean the
cache folders (we can't have two eln with the same 'path_hash', one must
be obsolete).

  Andrea

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Andrea Corallo  writes:
>> In general, is this hardcoded or can we change the hashing strategy for
>> Cygwin via some configuration or hook?
>
> Hardcoded. Could you explain why this could be problematic for cygwin?

It's not preblematic per se, I am just trying to figure out what the
options are to deal with the fact that rebase is host specific while the
cache is not.

> Note we use the absolute location hash mainly to try to keep clean the
> cache folders (we can't have two eln with the same 'path_hash', one must
> be obsolete).

Understood.  I'll try to trawl the old threads some time and may come
back with more questions. :-)


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

bug#50666: 28.0.50; Fix native compilation on Cygwin

[ASSI]

Eli Zaretskii writes:
> This means that the following situation will predictably fail:
>
>   . Emacs session A (or just some shell command) rebases a .eln file
>   . Emacs session B decides it needs to load that .eln
>
> What kind of failure will session B see in this case?  Is it possible
> to figure out somehow that this is the reason, so that we could
> instead try loading the .elc or .el?

Something like EPERM I'd think, and only very briefly (i.e. if you tretry
the exact same call it will usually succeed).  We could rename the file
while operating on it, but that just moves the point of where the file
system race is happening and makes the window a tiny bit smaller.

What do you do on Linux in the case that two processes try to generate
the same .eln?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Cc: 50666@debbugs.gnu.org
> Date: Fri, 24 Sep 2021 07:32:11 +0000
> From:  Andrea Corallo via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> > Can you point me to the part of the discussion where it was determined
> > that the absolute location of the file was making a difference that was
> > not covered with the hash of the content?
> 
> Not at the moment sorry, this was discussed more the once in different
> threads in the last 1-2 years.

Right.

One situation that comes to mind is that a .el file could be
native-compiled with different versions of macros in scope, although
that is not necessarily evidenced by the file's absolute name.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: ASSI <Stromeko@nexgo.de>
> Cc: ASSI <Stromeko@nexgo.de>,  50666@debbugs.gnu.org,  akrl@sdf.org
> Date: Fri, 24 Sep 2021 11:15:50 +0200
> 
> What do you do on Linux in the case that two processes try to generate
> the same .eln?

The OS takes care of that (it makes the first one invisible in the
filesystem when the second one is created, and will delete the first
one when the session using it exits).

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: ASSI <Stromeko@nexgo.de>, 50666@debbugs.gnu.org, kbrown@cornell.edu
> Date: Fri, 24 Sep 2021 07:26:11 +0000
> 
> > Or maybe we should add an automatic fallback on .elc/.el in case
> > loading a .eln fails?  Andrea, WDYT? will that work?
> 
> Yes I think we could have an automatic fallback, we might have
> 'native-elisp-load' (invoked by 'load') re invoke load itself in case of
> failure, not very clean tho.

Is 'native-elisp-load' always called from 'load'?  If so, we could
make it return some special value to signal that fallback is in order,
and then modify 'load' to proceed with loading *.el/*.elc file in that
case.

> But aside the fact that is implementable I think it should be limited to
> just this specific load failure, otherwise it could easily mask other
> issues.

We could log a message in *Messages* about this, so that the fallback
could be discovered.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: ASSI <Stromeko@nexgo.de>, 50666@debbugs.gnu.org, kbrown@cornell.edu
>> Date: Fri, 24 Sep 2021 07:26:11 +0000
>> 
>> > Or maybe we should add an automatic fallback on .elc/.el in case
>> > loading a .eln fails?  Andrea, WDYT? will that work?
>> 
>> Yes I think we could have an automatic fallback, we might have
>> 'native-elisp-load' (invoked by 'load') re invoke load itself in case of
>> failure, not very clean tho.
>
> Is 'native-elisp-load' always called from 'load'?

No but we could have it just return nil in case of fail with no
breakage.

> If so, we could
> make it return some special value to signal that fallback is in order,
> and then modify 'load' to proceed with loading *.el/*.elc file in that
> case.

Not sure how complex would be to integrate that with the controlo flow
in 'load' but yes that's a good idea if we wanna pursue this way.

  Andrea

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Date: Fri, 24 Sep 2021 13:48:09 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> 
> > Cc: 50666@debbugs.gnu.org
> > Date: Fri, 24 Sep 2021 07:32:11 +0000
> > From:  Andrea Corallo via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > > Can you point me to the part of the discussion where it was determined
> > > that the absolute location of the file was making a difference that was
> > > not covered with the hash of the content?
> > 
> > Not at the moment sorry, this was discussed more the once in different
> > threads in the last 1-2 years.
> 
> Right.
> 
> One situation that comes to mind is that a .el file could be
> native-compiled with different versions of macros in scope, although
> that is not necessarily evidenced by the file's absolute name.

I think I know what we were trying to solve by that, but the
explanation is a bit hairy.

It begins by noticing that what goes into the file-name part of the
hash is not the entire absolute file name.  We cannot use the entire
absolute file name, because then moving the .el files somewhere else
(e.g., to relocate the entire tree, or maybe access it from a
different machine) would break loading the *.eln files.  So we
actually disregard the leading directories, leaving just what's below
the 'lisp/' part.  For example, for a file "/foo/bar/baz/lisp/FOO.el"
we use just "//FOO.el".  And that could cause problems if we also have
"/foo/bar/baz/lisp/subdir/FOO.el".  So for the latter we use
"//subdir/FOO.el", which gives a different hash.

IOW, this is to be able to distinguish files with the same base name
that reside in different sub-directories of the same tree.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

On 9/23/2021 1:13 PM, Ken Brown wrote:
> On 9/23/2021 12:37 PM, Eli Zaretskii wrote:
>>> From: Ken Brown <kbrown@cornell.edu>
>>> Finally, as a side note, I don't think it would be a tragedy if this just turns
>>> out to be too complicated and we have to disable native compilation on 32-bit
>>> Cygwin.  The Cygwin home page at https://cygwin.com/ already contains the 
>>> following:
>>>
>>>     Address space is a very limiting factor for Cygwin. These days, a full
>>>     32 bit Cygwin distro is not feasible anymore, and will in all likelihood
>>>     fail in random places due to an issue with the fork(2) system call.
>>>
>>>     Therefore we recommend using 32 bit Cygwin only in limited scenarios, with
>>>     only a minimum of necessary packages installed, and only if there's no way
>>>     to run 64 bit Cygwin instead.
>>
>> 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.
> 
> Well, 32-bit Cygwin is already a second-class citizen, so we might just have to 
> do that whether someone objects or not.

32-bit Cygwin has just been demoted to a third-class citizen.  Cygwin 3.3.0 was 
released this morning, with a deprecation notice that it is the last major 
version supporting 32-bit installations.  In view of this, I don't want to put 
any energy into supporting native compilation on 32-bit Cygwin, and I doubt if 
Achim does either.

Eli, what do you think of the attached (assuming Achim agrees)?

Ken

[-- Attachment #2: 0001-Drop-support-for-native-compilation-on-32-bit-Cygwin.patch --]
[-- Type: text/plain, Size: 1063 bytes --]

From 7299a38ef7a6eced22b9506e0f68416fdb06986b Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Fri, 8 Oct 2021 14:29:08 -0400
Subject: [PATCH] Drop support for native compilation on 32-bit Cygwin

* configure.ac [i686-pc-cygwin]: Don't allow native compilation
unless ENABLE_NATIVE=yes.  (Bug#50666)
---
 configure.ac | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/configure.ac b/configure.ac
index e6ffea0637..0ddf917de2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3814,6 +3814,13 @@ AC_DEFUN
 HAVE_NATIVE_COMP=no
 LIBGCCJIT_LIBS=
 LIBGCCJIT_CFLAGS=
+if test "$canonical" = i686-pc-cygwin && \
+  test "${with_native_compilation}" != no && \
+  test "x${NATIVE_ENABLED}" != xyes; then
+    AC_MSG_ERROR([Native compilation is not supported on 32-bit Cygwin.
+If you want to try it anyway, reconfigure with NATIVE_ENABLED=yes.])
+fi
+
 if test "${with_native_compilation}" != "no"; then
     if test "${HAVE_PDUMPER}" = no; then
        AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
-- 
2.33.0

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Date: Thu, 28 Oct 2021 18:22:28 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org, akrl@sdf.org
> 
> 32-bit Cygwin has just been demoted to a third-class citizen.  Cygwin 3.3.0 was 
> released this morning, with a deprecation notice that it is the last major 
> version supporting 32-bit installations.  In view of this, I don't want to put 
> any energy into supporting native compilation on 32-bit Cygwin, and I doubt if 
> Achim does either.
> 
> Eli, what do you think of the attached (assuming Achim agrees)?

Assuming this decision of the Cygwin developers is final, I don't
mind.  But why do we want to depend on an environment variable for
enabling the 32-bit build? why not a configure-time command-line
option?

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On 10/29/2021 1:55 AM, Eli Zaretskii wrote:
>> Date: Thu, 28 Oct 2021 18:22:28 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> Eli, what do you think of the attached (assuming Achim agrees)?
> 
> Assuming this decision of the Cygwin developers is final, I don't
> mind.  But why do we want to depend on an environment variable for
> enabling the 32-bit build? why not a configure-time command-line
> option?

Thanks for the suggestion.  How's this?

Ken

[-- Attachment #2: 0001-Drop-support-for-native-compilation-on-32-bit-Cygwin.patch --]
[-- Type: text/plain, Size: 1755 bytes --]

From 084b03ae1f81c72a46d4f365c50851db3674b4c1 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Fri, 29 Oct 2021 11:38:55 -0400
Subject: [PATCH] Drop support for native compilation on 32-bit Cygwin

* configure.ac (cygwin32-native-compilation): New option.
[i686-pc-cygwin]: Don't allow native compilation unless that
option is specified.  (Bug#50666)
---
 configure.ac | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/configure.ac b/configure.ac
index e6ffea0637..6bc194d792 100644
--- a/configure.ac
+++ b/configure.ac
@@ -485,6 +485,7 @@ AC_DEFUN
 OPTION_DEFAULT_ON([modules],[don't compile with dynamic modules support])
 OPTION_DEFAULT_ON([threads],[don't compile with elisp threading support])
 OPTION_DEFAULT_OFF([native-compilation],[compile with Emacs Lisp native compiler support])
+OPTION_DEFAULT_OFF([cygwin32-native-compilation],[use native compilation on 32-bit Cygwin])
 
 AC_ARG_WITH([file-notification],[AS_HELP_STRING([--with-file-notification=LIB],
  [use a file notification library (LIB one of: yes, inotify, kqueue, gfile, w32, no)])],
@@ -3814,6 +3815,16 @@ AC_DEFUN
 HAVE_NATIVE_COMP=no
 LIBGCCJIT_LIBS=
 LIBGCCJIT_CFLAGS=
+if test "$canonical" = i686-pc-cygwin; then
+  if test "${with_cygwin32_native_compilation}" = yes; then
+    with_native_compilation=yes
+  elif test "${with_native_compilation}" != no; then
+    AC_MSG_ERROR([Native compilation is not supported on 32-bit Cygwin.
+If you really want to try it anyway, use the configure option
+'--with-cygwin32-native-compilation'.])
+  fi
+fi
+
 if test "${with_native_compilation}" != "no"; then
     if test "${HAVE_PDUMPER}" = no; then
        AC_MSG_ERROR(['--with-native-compilation' requires '--with-dumping=pdumper'])
-- 
2.33.0

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Date: Fri, 29 Oct 2021 13:03:29 -0400
> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org, akrl@sdf.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> > Assuming this decision of the Cygwin developers is final, I don't
> > mind.  But why do we want to depend on an environment variable for
> > enabling the 32-bit build? why not a configure-time command-line
> > option?
> 
> Thanks for the suggestion.  How's this?

LGTM, thanks.

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 10/29/2021 2:02 PM, Eli Zaretskii wrote:
>> Thanks for the suggestion.  How's this?
> 
> LGTM, thanks.

OK, I'll wait a few days before pushing it, in case Achim wants to chime in.

Ken

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Achim Gratz]

Ken Brown writes:
> On 10/29/2021 2:02 PM, Eli Zaretskii wrote:
>>> Thanks for the suggestion.  How's this?
>> LGTM, thanks.
>
> OK, I'll wait a few days before pushing it, in case Achim wants to chime in.

Go ahead.  While it's somewhat unsatisfatory to drop the ball like this,
I also don't see it as a good investment of time to get to the bottom of
the (multiple) issues at play.  The outcome might still be that it
doesn't quite work even if we'd get there.  If somebody is interested
enough we'll hear of it I'd think.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#50666: 28.0.50; Fix native compilation on Cygwin

[Ken Brown]

On 10/31/2021 4:22 PM, Achim Gratz wrote:
> Ken Brown writes:
>> On 10/29/2021 2:02 PM, Eli Zaretskii wrote:
>>>> Thanks for the suggestion.  How's this?
>>> LGTM, thanks.
>>
>> OK, I'll wait a few days before pushing it, in case Achim wants to chime in.
> 
> Go ahead.  While it's somewhat unsatisfatory to drop the ball like this,
> I also don't see it as a good investment of time to get to the bottom of
> the (multiple) issues at play.  The outcome might still be that it
> doesn't quite work even if we'd get there.  If somebody is interested
> enough we'll hear of it I'd think.

I've pushed it and am closing this bug report for now.  We can always revisit it 
later.

Ken