From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <920-082-4242@kylheku.com> Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id 4C5B9394741A for ; Wed, 8 Apr 2020 20:50:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4C5B9394741A Received: from kylheku.com ([70.79.163.252]) by shaw.ca with ESMTPA id MHe7jruR362brMHe8jdDGK; Wed, 08 Apr 2020 14:50:05 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=cl8xLZFz6L8A:10 a=5LdAx3Pn9XBJBE5jo58A:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <920-082-4242@kylheku.com>) id 1jMHe6-0006Hz-U3; Wed, 08 Apr 2020 13:50:02 -0700 To: =?UTF-8?Q?=C3=85ke_Rehnman?= Subject: Re: Using ARM GNU GCC with Cygwin X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 08 Apr 2020 13:50:02 -0700 From: Kaz Kylheku <920-082-4242@kylheku.com> Cc: cygwin@cygwin.com Organization: Cygwin Mailing List In-Reply-To: <38a47b9b-f43a-3727-2205-f02f0dbd48d0@gmail.com> References: <51717d4a9c861fd90b5f9a58b84b308a@mail.kylheku.com> <38a47b9b-f43a-3727-2205-f02f0dbd48d0@gmail.com> Message-ID: <867844f7772cbc73326eeb57b85a0ab8@mail.kylheku.com> X-Sender: 920-082-4242@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfHKKbvGN6zc4L4l+8nzWTzAXRJ42Ec3kxXlsPd4N3tjLw4jgGQxi77N4UOyGp7E48c1iXi5tZ6vRsxvhhDB2EiLYqGIc/K7j14F3AaZNZD04/8mb9YJQ jiBwoXYHREh7E9AVKhINK/aQdReKtat7Hs2b0f2gXvXbSYPAFbzCV1msjoBO8pJ85WHDelmTLdoudku+18dU35M3MAW8FvAFWbk= X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20, FROM_STARTS_WITH_NUMS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 20:50:08 -0000 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.)