2009-12-30 15 views
16

Digamos que tengo una aplicación que compilé bajo cygwin, y quiero distribuir esa aplicación sin que el usuario tenga que instalar cygwin. ¿Sería suficiente empaquetar el archivo ejecutable y el archivo DLL cygwin?Ejecutando una aplicación, compilada en cygwin, sin haber instalado cygwin

+3

La DLL de cygwin es GPL, por lo que también tendría que distribuir la fuente de su aplicación. –

+0

Pero puede comprar una licencia comercial para Cygwin. –

+0

Por favor, elabore - porque parece haber dos tipos de interpretación en las respuestas. ¿Quiere decir esto técnicamente (qué otros * archivos * necesito distribuir) o legalmente (qué me permite la licencia)? – Wim

Respuesta

2

Normalmente, sí. Asegúrese de instalar la DLL de Cygwin en una ubicación pública (Windows \ System32), esta DLL se comporta muy mal cuando se cargan múltiples versiones de la misma máquina.

+1

[Vinculación de GPL y trabajos derivados] (http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works) –

+1

La pregunta no indicaba nada acerca de que el autor no publicara el código. Muchas utilidades incluyen un cygwin1.dll. Un ejemplo de esto es cntml: http://cntlm.sourceforge.net/. – brianegge

0

Puede intentar compilar todo como estático. Eso debería permitirle ejecutar todo sin la necesidad de libs (dado que ya están en su binario). Pero esto también significa que podría no funcionar todas las plataformas si cygwin necesitaría una dll diferente o más nueva.

+0

Eso no funcionará: http://stackoverflow.com/questions/340696/can-you-statically-compile-a-cygwin-application – Hut8

3

¿Su aplicación realmente necesita alguna emulación Posix proporcionada por Cygwin? De lo contrario, puede compilarlo con el indicador -mno-cygwin y no dependerá en absoluto de cygwin, sino que será una aplicación nativa de Windows. A menudo, solo necesitas un shell real (bash) para configurar y crear tu aplicación, pero en realidad no necesitas la funcionalidad de Posix de Cygwin.

Otra alternativa es MSYS + MinGW, que es un tenedor liviano de Cygwin. Esto proporciona un entorno de compilación que produce aplicaciones nativas de Windows de forma predeterminada.

Una tercera opción sería usar los compiladores MinGW de la propia Cygwin. Deben estar disponibles a través del administrador de paquetes normal de Cygwin. Luego configuraría el proyecto para una compilación cruzada usando los compiladores MinGW.

+0

MSYS no es una bifurcación de cygwin. –

+1

http://www.mingw.org/history http://en.wikipedia.org/wiki/MinGW#Comparison_with_Cygwin Además, los tipos principales en la lista de correo de MinGW a menudo dicen que MinGW/MSYS es una bifurcación de cygwin. –

+0

MinGW no es MSYS –

2

Las cosas han cambiado. Las bibliotecas de Cygwin están ahora bajo Lesser GPL (v3), lo que permite agruparlas con aplicaciones que se encuentran dentro de una amplia gama de licencias, desde FOSS hasta propietarias.

Lo que se interpone es que la emulación POSIX en Cygwin lleva las cosas un poco lejos de la perspectiva de las aplicaciones nativas de Windows.

Aquí es donde entra en juego mi proyecto Cygnal. Cygnal significa Biblioteca de aplicaciones nativas CYGwin: es una horquilla de Cygwin compatible con la función de inserción que cambia, o en algunos casos simplemente reconfigura, los comportamientos de ciertas funciones en orden para cumplir con las convenciones nativas de la plataforma de Windows.

Un programa básico "Hello, World" de Cygwin requiere dos bibliotecas. Un tiempo de ejecución de GCC llamado cyggcc_s-1.dll y la DLL de Cygwin cygwin1.dll. El proyecto Cygnal proporciona un reemplazo para este último. (Una versión de 32 bits está disponible para descargar).

Un área evidente de incompatibilidad entre la vista mundial de Cygwin POSIX y Windows es el manejo de rutas. La vista de Cygwin del sistema de archivos es a través de un falso directorio raíz /, y su propia "tabla de montaje" interna que proporciona espacios como /cygdrive, /proc y /dev. Cygnal elimina todo eso. Las rutas son rutas de Win32. El directorio de trabajo actual se comporta como el directorio de trabajo actual de Windows. Las unidades están asociadas a los directorios actuales, y las rutas relativas de la unidad como D:foo.txt funcionan bajo Cygnal. Debajo de Cygnal, /dev y /proc todavía están disponibles: se accede como los prefijos especiales dev:/ y proc:/. No está permitido chdir en estos: ¡eso no sería nativo! En Cygnal, si chdir a D:\wherever, entonces su unidad actual es la unidad D, y las rutas /foo o \foo se refieren a D:\foo.El principal directorio raíz POSIX de Cygwin ya no está.

Sin embargo, con Cygnal, puede continuar utilizando la funcionalidad POSIX, lo que permite desarrollar programas multiplataforma que tienen menos código que se conmuta en función de la plataforma, en comparación con mantener un puerto con MinGW o Microsoft Visual C/C++.

Por ejemplo: puede escribir una aplicación de consola Win32 utilizando códigos VT100 y termios. El mismo código se ejecutará en Unixes. No es necesario utilizar la API de la consola Win32 en Windows y VT100/termios en un sistema POSIX.

Otro ejemplo: para enhebrar, puede simplemente usar hilos POSIX. pthread_create para iniciar un hilo, pthread_mutex_lock para bloquear un mutex y así sucesivamente. Su programa no necesita una abstracción de portabilidad para hilos que se traduce en Win32 o POSIX; solo usas el POSIX y listo.

La función uname en Cygnal informa el sysname con un prefijo CYGNAL en lugar de CYGWIN. Por medio de esto, su programa puede decir que se está ejecutando en Cygnal en lugar de Cygwin (o cualquier otra plataforma POSIX). Por lo tanto, puede hacer los ajustes necesarios: por ejemplo, si su programa necesita /dev/null, en Cygnal puede buscar dev:/null en su lugar.