This is the mail archive of the
mailing list for the Cygwin project.
Re: distinguishing cygwin from mingw binaries
- From: cyg Simple <cygsimple at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 11 Jul 2017 10:43:10 -0400
- Subject: Re: distinguishing cygwin from mingw binaries
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
On 7/10/2017 2:00 PM, Kaz Kylheku wrote:
> On 10.07.2017 10:40, Nellis, Kenneth wrote:
>> For my personal use, I use gcc to generate binaries, but occasionally
>> I need
>> to make a binary available to someone who doesn't use Cygwin. For that
>> I use
>> Cygwin's x86_64-w64-mingw32-gcc.
>> After the fact, I would like to know whether the binary requires
>> Cygwin support
>> or not. One way is: strings foo.exe | grep cygwin1.dll
>> Curious what techniques others might use.
> There is always the technique of actually packaging the program
> and then testing them, beginning with installation, if you were the
> If the program doesn't run when installed by itself in C:\Program Files
> somewhere, then it might be missing DLLs.
> I use a special fork of Cygwin called Cygnal for delivering programs to
> users who don't use Cygwin and don't understand POSIX conventions for paths
> and other things.
> With this, you make your executable with the regular Cygwin host compiler.
> Yes, you know your executable needs a CYGWIN1.DLL (and possibly others);
> no guesswork. You package the needed DLL's with the program.
> Except, you use the CYGWIN1.DLL from the Cygnal project rather than the
> stock Cygwin one.
> Example software shipping with Cygnal is the port of the TXR language to
> Win32 and Win64. Installers available here:
CAUTION: This requires you provide the entire source set of Cygnal since
it is actually Cygwin which has the GPL license applied to it. You
might as well package Cygwin1.dll itself.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple