Using ARM GNU GCC with Cygwin

[Kaz Kylheku]

On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
> On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote:
>> On 2020-04-04 02:00, Ben wrote:
>>> Is there something else I'm missing?
>> 
>> That by cross-compiling for your targets on Cygwin instead of a real 
>> POSIX OS, you will something like double your compile times, if not 
>> more.
>> 
>> Why would you involve Cygwin in a development activity whose target 
>> isn't POSIX on Windows.
> 
> Most strange comment I have read... With your reasoning why bother
> with cygwin at all for any reason?

There are excellent reasons, obviously:


Firstly: to have a familiar POSIX environment available on Windows,
for personal use, where Windows is dictated by a workplace.

For instance, one use case of mine for dropping into Cygwin is
to run ImageMagick's convert command to either convert a .pdf
file into multiple .png files or vice versa. This is in the
context of work e-mails (Outlook, Exchange, ...).

I have a major use case for Cygwin for providing remote access
to Windows. Using a non-Cygwin utility called "RunAsService.EXE",
I turned a Cygwin Bash script into a Windows service. This Bash
script loops around and makes a SSH connection to a host
in a domain that I control, setting up a tunnel for port 3389
(RDP). From that domain, I can then remote desktop into the
Windows system. Basically I can deploy this solution on any
Windows machine on any network where outbound SSH is allowed, and
have remote access to it.


Secondly: to port stuff to Windows that has to run on Windows for
reasons like the target users being tied to Windows, yet uses
lots of POSIX API's.

"A cross-compiling GNU toolchain" isn't an example of an application
that must run on Windows. It's not shipped to users. The system/device
being targeted by the cross-compiling is what is shipped to users.

Why wouldn't you use the best possible environment for that,
on a robust, fast OS.

OP has explained that he's just curious to get that working, and
there is certainly nothing wrong with that.

I certainly don't want to dictate to him what he should find
interesting and motivating; that was not the intent of my remark.

I also must acknowledge the following: there may be a situation
whereby the embedded system in question (quite stupidly, but
out of your control) requires communication with Windows for
some procedure like flashing part of the firmware or something
(say over USB). The people responsible for that developed a
utility which only runs on Windows. If you can build on Windows,
then the whole workflow is easily streamlined, including the part
where you have to kick off the FOOBAR.EXE to do that annoying step.
It nicely runs on just one machine without any extra copying of
images and whatnot.

(Yes, I've dealt with stuff like that, but usually outside of the
regular dev cycle. Like say for flashing an low-level bootloader
not touched by regular rebuilds of the main image, or recovering
a totally "bricked" unit and such.)