Angenommen, ich habe eine Anwendung, die ich unter cygwin kompiliert habe, und ich möchte diese Anwendung verteilen, ohne dass der Benutzer cygwin installieren muss. Wäre es genug, um die ausführbare Datei und die Cygwin-DLL zu packen?Ausführen einer in cygwin kompilierten Anwendung, ohne cygwin installiert zu haben
Normalerweise ja. Stellen Sie sicher, dass Sie die Cygwin-DLL an einem öffentlichen Speicherort installieren (Windows \ System32), diese DLL verhält sich jedoch sehr schlecht, wenn mehrere Versionen derselben auf demselben Computer geladen sind.
[GPL Linking und abgeleitete Werke] (http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works) –
Die Frage ergab nichts über den Autor, der den Code nicht freigibt. Viele Dienstprogramme bündeln eine cygwin1.dll. Ein solches Beispiel ist cntml: http://cntlm.sourceforge.net/. – brianegge
Sie könnten versuchen, alles als statisch zu kompilieren. Das sollte dir erlauben, alles ohne die libs auszuführen (da sie bereits in deiner Binärdatei sind). Aber dies wird auch bedeuten, dass es nicht alle Plattformen funktionieren könnte, wenn Cygwin eine andere oder neuere DLL benötigen würde.
Das wird nicht funktionieren: http://stackoverflow.com/questions/340696/can-you-statical-compile-a-cygwin-application – Hut8
Benötigt Ihre Anwendung tatsächlich eine von Cygwin bereitgestellte Posix-Emulation? Wenn nicht, können Sie es mit dem -mno-cygwin-Flag kompilieren und es wird nicht von Cygwin abhängig sein, sondern wird eine native Windows-Anwendung sein. Oft benötigen Sie nur eine echte Shell (bash), um Ihre Anwendung zu konfigurieren und zu erstellen, aber Sie brauchen die Posix-Funktionalität von Cygwin nicht. Eine andere Alternative ist MSYS + MinGW, die eine leichte Gabel von Cygwin ist. Dies bietet eine Kompilierungsumgebung, die standardmäßig native Windows-Apps erstellt.
Eine dritte Option wäre, die MinGW-Compiler von Cygwin selbst zu verwenden. Sie sollten über den normalen Cygwin-Paketmanager verfügbar sein. Dann würden Sie das Projekt für eine Kreuzkompilierung mit den MinGW-Compilern konfigurieren.
MSYS ist keine Abzweigung von Cygwin. –
http://www.mingw.org/history http://en.wikipedia.org/wiki/MinGW#Comparison_with_Cygwin Darüber hinaus sagen die wichtigsten Leute auf der MinGW Mailingliste oft, dass MinGW/MSYS eine Gabel von Cygwin. –
MinGW ist nicht MSYS –
Die Dinge haben sich geändert. Die Cygwin-Bibliotheken sind nun unter der Lesser-GPL (v3), die es ermöglicht, sie mit Anwendungen zu kombinieren, die unter eine breite Palette von Lizenzen fallen, von FOSS bis zu proprietären.
Was ist im Weg ist, dass die POSIX-Emulation in Cygwin Dinge ein wenig zu weit aus der Perspektive der nativen Windows-Anwendungen nimmt.
Dies ist, wo mein Cygnal Projekt an Cygnal steht für Cygwin native Application Library. Es ist ein Drop-in-kompatibel Gabel von Cygwin, die sich ändert, oder in einigen Fällen einfach neu konfiguriert, das Verhalten bestimmter Funktionen, um um den nativen Konventionen der Windows-Plattform zu entsprechen.
Ein einfaches "Hello, World" Cygwin-Programm benötigt zwei Bibliotheken. Eine GCC-Laufzeit mit der Bezeichnung cyggcc_s-1.dll und der Cygwin-DLL cygwin1.dll. Das Cygnal-Projekt bietet einen Ersatz für Letzteres. (Ein 32-Bit-Build steht zum Download zur Verfügung).
Ein greller Bereich der Inkompatibilität zwischen der Cygwin POSIX-Sicht der Welt und Windows ist die Pfadbehandlung. Die Cygwin-Ansicht des Dateisystems läuft über ein falsches / Stammverzeichnis und eine eigene interne "Mount-Tabelle", die Leerzeichen wie , /proc und /dev bereitstellt. Cygnal macht das alles überflüssig. Pfade sind Win32-Pfade. Das aktuelle Arbeitsverzeichnis verhält sich wie das aktuelle Arbeitsverzeichnis von Windows. Laufwerke sind aktuellen Verzeichnissen zugeordnet, und relative Pfade wie D:foo.txt funktionieren unter Cygnal. Unter Cygnal sind /dev und /proc immer noch verfügbar: Sie werden als die speziellen Präfixe dev:/ und proc:/ zugegriffen. Es ist nicht erlaubt zu chdir in diese: das wäre nicht nativ! Unter Cygnal, wenn Sie chdir zu D:\wherever dann Ihr aktuelles Laufwerk ist die Laufwerk, und die Pfade /foo oder \foo beziehen sich auf D:\foo.Cygwins Master-POSIX-Stammverzeichnis ist weg.
Mit Cygnal können Sie weiterhin die POSIX-Funktionalität verwenden, die es ermöglicht, plattformübergreifende Programme mit weniger Code zu entwickeln, der plattformabhängig geschaltet wird, im Vergleich zur Verwaltung eines Ports mit MinGW oder Microsoft Visual C/C++.
Zum Beispiel: Sie können eine Win32-Konsolenanwendung mit VT100-Codes und termios schreiben. Derselbe Code wird unter Unix ausgeführt. Sie müssen die Win32-Konsolen-API unter Windows und VT100/termios auf einem POSIX-System nicht verwenden.
Ein anderes Beispiel: Zum Threading können Sie nur POSIX-Threads verwenden. pthread_create zum Starten eines Threads, pthread_mutex_lock zum Sperren eines Mutex und so weiter. Ihr Programm benötigt keine Portabilitätsabstraktion für Threads, die in Win32 oder POSIX übersetzt werden; Sie benutzen einfach das POSIX und das war's.
Die uname Funktion in Cygnal berichtet die sysname mit einem CYGNAL Präfix statt CYGWIN. Dadurch kann Ihr Programm feststellen, dass es auf Cygnal und nicht auf Cygwin (oder einer anderen POSIX-Plattform) läuft. So können Sie notwendige Anpassungen vornehmen: Wenn Ihr Programm beispielsweise /dev/null benötigt, kann es auf Cygnal stattdessen nach dev:/null suchen.
Die cygwin DLL ist GPL, also müssten Sie auch die Quelle Ihrer App verteilen. –
Aber Sie können eine kommerzielle Lizenz für Cygwin kaufen. –
Bitte erläutern Sie, denn es scheint zwei Arten von Interpretationen in den Antworten zu geben. Meinst du das technisch (welche * anderen * Dateien muss ich verteilen), oder legal (was erlaubt mir die Lizenz)? – Wim