From 03b7882aa0eb4b772f9bbf51df22145412bc27cd Mon Sep 17 00:00:00 2001 From: Yaakov Selkowitz Date: Wed, 18 Jul 2012 02:11:04 +0000 Subject: [PATCH] * faq-programming.xml (faq.programming.unix-gui): Update to reflect the availability of X11 toolkits on Cygwin. --- winsup/doc/ChangeLog | 5 ++++ winsup/doc/faq-programming.xml | 52 +++++++++++++++++++++++++--------- 2 files changed, 43 insertions(+), 14 deletions(-) diff --git a/winsup/doc/ChangeLog b/winsup/doc/ChangeLog index 5f3b3561b..91b41a820 100644 --- a/winsup/doc/ChangeLog +++ b/winsup/doc/ChangeLog @@ -1,3 +1,8 @@ +2012-07-17 Yaakov Selkowitz + + * faq-programming.xml (faq.programming.unix-gui): Update to + reflect the availability of X11 toolkits on Cygwin. + 2012-06-03 Corinna Vinschen * new-features.sgml (ov-new1.7.16): Document ReFS support. diff --git a/winsup/doc/faq-programming.xml b/winsup/doc/faq-programming.xml index 4aecdc3bf..6e1edda65 100644 --- a/winsup/doc/faq-programming.xml +++ b/winsup/doc/faq-programming.xml @@ -810,20 +810,44 @@ a Windows environment which Cygwin handles automatically. How should I port my Unix GUI to Windows? -There are two basic strategies for porting Unix GUIs to Windows. - -The first is to use a portable graphics library such as tcl/tk, X11, or -V (and others?). Typically, you will end up with a GUI on Windows that -requires some runtime support. With tcl/tk, you'll want to include the -necessary library files and the tcl/tk DLLs. In the case of X11, you'll -need everyone using your program to have the X11 server installed. - -The second method is to rewrite your GUI using Win32 API calls (or MFC -with VC++). If your program is written in a fairly modular fashion, you -may still want to use Cygwin if your program contains a lot of shared -(non-GUI-related) code. That way you still gain some of the portability -advantages inherent in using Cygwin. - +Like other Unix-like platforms, the Cygwin distribtion includes many of +the common GUI toolkits, including X11, X Athena widgets, Motif, Tk, GTK+, +and Qt. Many programs which rely on these toolkits will work with little, if +any, porting work if they are otherwise portable. However, there are a few +things to look out for: + +Some packages written for both Windows and X11 incorrectly +treat Cygwin as a Windows platform rather than a Unix variant. Mixing Cygwin's +Unix APIs with Windows' GDI is best avoided; rather, remove these assumptions +so that Cygwin is treated like other X11 platforms. +GTK+ programs which use gtk_builder_connect_signals() +or glade_xml_signal_autoconnect() need to be able to +dlopen() themselves. In order for this to work, the program +must be linked with the -Wl,--export-all-symbols linker flag. +This can be added to LDFLAGS manually, or handled automatically with the +-export-dynamic libtool flag (requires libtool 2.2.8) or +by adding gmodule-export-2.0 to the pkg-config modules used +to build the package. +Programs which include their own loadable modules (plugins) +often must have its modules linked against the symbols in the program. The +most portable solution is for such programs to provide all its symbols (except +for main()) in a shared library, against which the plugins +can be linked. Otherwise, the symbols from the executable itself must be +exported. +If the package uses the CMake build system, this can be done by adding +ENABLE_EXPORTS TRUE to the executable's set_target_properties +command, then adding the executable's target name to the target_link_libraries +command for the plugins. +For other build systems, the following steps are required: + +The executable must be built before its plugins. +Symbols must be exported from the executable with a +-Wl,--export-all-symbols,--out-implib,libfoo.exe.a +linker flag, where foo represents the name of the +executable. +The plugins must be linked with a -Wl,/path/to/libfoo.exe.a +linker flag. +