From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31913 invoked by alias); 16 Aug 2014 19:15:18 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 31903 invoked by uid 89); 16 Aug 2014 19:15:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_20,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f50.google.com Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 16 Aug 2014 19:15:16 +0000 Received: by mail-wg0-f50.google.com with SMTP id n12so3377940wgh.21 for ; Sat, 16 Aug 2014 12:15:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.8.35 with SMTP id o3mr29634235wja.3.1408216513687; Sat, 16 Aug 2014 12:15:13 -0700 (PDT) Received: by 10.180.238.66 with HTTP; Sat, 16 Aug 2014 12:15:13 -0700 (PDT) In-Reply-To: <53EF5552.4070807@si6networks.com> References: <53ED67D3.2020405@si6networks.com> <877g28enhq.fsf@Rainer.invalid> <20140816104904.GV28562@calimero.vinschen.de> <53EF5552.4070807@si6networks.com> Date: Sat, 16 Aug 2014 19:15:00 -0000 Message-ID: Subject: Re: Running a cygwin application on Windows From: Michael DePaulo To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00320.txt.bz2 On Sat, Aug 16, 2014 at 8:57 AM, Fernando Gont wrote: > On 08/16/2014 06:49 AM, Corinna Vinschen wrote: >> On Aug 16 12:29, Achim Gratz wrote: >>> Fernando Gont writes: >>>> My idea was to use cygwin, since I'm not much of a Windows programmer. >>>> Is there any way to produce and ship an exe with the relevant libraries? >>> >>> If I understand correctly what you're trying to do, you need to obtain a >>> commercial license from RedHat for doing so. Otherwise, if you ship >>> binaries linked against cygwin1.dll you need to also include all sources >>> (for Cygwin and your own application) with each such shipment. >> >> You only need the buyout license if you want to provide binaries only. >> But this is a GPL'ed project, so I assume there's no desire to create >> binary-only packages. > > To be as honest and straightforward as possible :-): My goal is to > provide as may options as possible. I will be producing a Cygwin package > since that seems to be a fair way to contribute to this project. But I > also want to address the user that just knows how to run commands from > the windows command line and wants to quickly download & install my > toolkit to try it. -- hence my goal of also producing some sort of > "binary" distribution (even if the binary package also includes the source). > > I'm in the process of reading the online information to produce the > Cygwin package. Are there any pointers to get the other stuff done? > > Thanks! > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 [...] Hi Fernando, I'm a volunteer contributor to the open source project X2Go. In addition to producing a Cygwin package, you might want to do what we currently do for the Windows builds of X2Go Client. We provide 5 binaries linked against cygwin .DLL files. They are nxproxy.exe (part "nx-libs", maintained by our project), and 4 patched OpenSSH binaries: sftp.exe sftp-server.exe ssh-keygen.exe sshd.exe (We of course provide the source code.) Our build process needs improvement. But for now, after building those binaries, our solution is to manually copy all of the following into one single directory: 1. Those 5 binaries 2. All their cygwin .DLL dependencies 3. sh.exe We then call the cygwin-built binaries from our native win32 app, x2goclient.exe, like any other command-line binary. We can also call them from cmd.exe. We include the files (in one directory) as part of our NSIS installer That's all there is to it if you only care about a small number of our binaries working, and their dependencies don't require any directory structure. ---- More info: 1. Our entire Windows build process is documented here. : http://wiki.x2go.org/doku.php/wiki:development:build-howto-mswin:x2goclient 2. How we handle Cygwin updates is a larger discussion. Basically, whenever we update cygwin, we rebuild our .binaries. And I monitor cygwin-announce for any security updates. Usually when there is a security update (e.g., to openssl), we update the vulnerable.DLL files individually and refer to it as a new "build" of x2goclient at version X. 3. We do not package nx-libs for Cygwin because it is useless without X2Go Client for Windows, which is only available for native win32, and which in turn has native win32 dependencies. 4. We do not try to upstream our SSH patch because it is specific to X2Go's needs. 5. You can determine what source package a file is from by running "cygcheck". For example: $ cygcheck -f /usr/bin/cygcrypto-1.0.0.dll libopenssl100-1.0.1i-1 I do not know of an easy way to determine what binary package it is from. However, the cygwin mirrors keep all the binary packages (and the 1 source package) under a directory named after the source package. For example: ftp://mirrors.kernel.org/sourceware/cygwin/x86/release/openssl/ So after looking at the contents of the tarballs, I found it in this binary package ftp://mirrors.kernel.org/sourceware/cygwin/x86/release/openssl/libopenssl100/libopenssl100-1.0.1i-1.tar.xz -Mike DePaulo -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple