Christopher Faylor wrote:
> On Mon, Sep 14, 2009 at 07:01:44PM -0400, Charles Wilson wrote:
>>From this thread:
>> http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html
>> I thought most people either were in favor of, or at least not opposed
>> to, "fixing" the */tk/*/insight issue by switching to an X-based tk. It
>> was just waiting on enough cgf-tuits (and, perhaps, the long-delayed gdb
>> 7.0 release and/or Insight 7.0).
>
> I did get tcl and (I think) tk building but then found that insight
> needed other libraries too.
Yep: Itcl, Itk, and Iwidgets.
I've got those, too, each built from the new "separate", TEA-compliant
source tarballs.
A quick-n-dirty build of insight (current CVS) seems to work with minor
patching. However...
there seems to be a lot of "entanglement" in the insight codebase. The
idea that "cygwin == win32 tcl" is an assumption that runs throughout
the code. For instance, a lot of stuff is guarded by '#ifdef _WIN32'
rather than one of
'#if defined(_WIN32) && !defined(__CYGWIN__)'
'#if defined(_WIN32) || defined(__CYGWIN__)'
or, the best alternative, something like
'#if defined(_WIN32_TCL)'
Also, the configury, by default, arranges for -D_WIN32 -mwin32. And,
even when you "fix" the configury to not do that, any time <windows.h>
is included it comes back, zombie-like.
And last, you have to use --disable-werror on cyg1.7 because insight
uses the old path conversion functions (cygwin_conv_to_full_win32_path
and friends), which causes deprecation warnings.
So, while my version seems to "work" in my brief testing -- it is
definitely a rough approximation to a true, cygwin/X version of insight.
I'm not sure anybody wants to put the effort into the dying insight
codebase to "do it right".
Now, whether insight is dropped or not, I still think it would be good
to have "real" X-based tcl/tk in the distro, even though that would
cause knock-on effects to expect, git, python [*], and ruby. The big
drawback last year was that at the time, we were still in limbo with
regards to a working cygwin xserver (we had the modularized libs, but
the xorg-7.x server was still WIP). That's no longer the case.
[*] for instance, the 'idle' GUI becomes X-based, as does gitk (and they
probably need recompilation or they'll simply break) -- (actually, gitk
seems to work as-is with the new tcl, tk packages).
If anybody is interested, I can put the following packages up on the web
somewhere, but they'd need a little TLC before being "correct" and
"official" cygwin replacements for tcltk. For instance, the
"unversioned" packages ['tcl', 'tk', etc] contain the unversioned "wish
-> wish8.5.exe" symlinks and /usr/share/doc/ stuff. This should
probably all be merged into the "main" versioned package (tcl -> tcl8.5,
etc) and the 'unversioned' symlinks removed, being replaced by
postinstall scripts that use /usr/sbin/alternatives. Which would have
ripple effects on all the .hint files throughout.
Also, I noticed that debian packages itcl, itk, and iwidgets using only
${MAJ}, not ${MAJ}.${MIN} -- that is:
tcl8.5 + tk8.5, but
itcl3 + itk3 + iwidgets4
I don't know why, and I did it differently for itcl and itk. Fedora,
OTOH, doesn't use version numbers for ANY of these package -- just:
tcl + tk + itcl + itk + iwidgets
???
We should probably either do it debian's way, or Fedora's way, or be
self consistent and always use ${MAJ}.${MIN} -- my current weirdness is
mostly likely badly wrong. My gut says its safer to follow the others'
lead -- one or the other; and I prefer the debian way for reasons
explained below.
And the READMEs all still claim that cygwin-ports maintains them, even
tho Yaakov has nothing to do with these "forks" of his ports (and I'm
not volunteering to take over these packages; too much on my plate,
honestly. I'd suck as the maintainer).
tcltk 20080420-2 (empty upgrade helper)
tcl 8.5.7-1
tcl8.5 8.5.7-1
tcl8.5-devel 8.5.7-1
tcl8.5-doc 8.5.7-1
tk 8.5.7-1
tk8.5 8.5.7-1
tk8.5-demo 8.5.7-1
tk8.5-devel 8.5.7-1
tk8.5-doc 8.5.7-1
tcl 3.4b1-1
itcl3.4 3.4b1-1
itcl3.4-devel 3.4b1-1
itcl3.4-doc 3.4b1-1
itk 3.3-1
itk3.3 3.3-1
itk3.3-devel 3.3-1
itk3.3-doc 3.3-1
iwidgets 4.0.2-1
iwidgets4 4.0.2-1
iwidgets4-demo 4.0.2-1
iwidgets4-doc 4.0.2-1
[1] Corinna mentioned that, because the current tcltk DLLs are named
"libtcl84.dll" and "libtk84.dll", we might retain transitional
compatibility with un-recompiled python, insight, git, etc, by modifying
the "new" tcl and tk build process to use the standard cygwin naming
convention of 'cyg*.dll'. The modified build process for the
TEA-compliant extensions itcl, itk, and iwidgets DOES do this. However,
I did not modify my ports of tcl and tk -- because we already HAVE that
win: the new dlls are named
libtcl8.5.dll (vs. libtcl84.dll)
libtk8.5.dll (vs. libtk84.dll)
So, transitional compatibility can be maintained [2] simply by repacking
the existing tcltk package so that it installs the necessary runtime 8.4
runtime files and DLLs (instead of the *empty* upgrade helper). This
package would need careful auditing to make sure that it (a) doesn't
conflict with stuff provided by the "new" packages (e.g. probably
removing ALL of the development files, and the unversioned wish.exe,
tclsh.exe, and *Config scripts) and (b) does provide what is necessary
for the current non-rebuilt incarnations of ruby, python, git, expect,
and insight. It's possible that (a) and (b) might be mutually exclusive.
As far as changing further the build process of the new tcl and tk
packages to use the 'cyg' prefix -- it can be done, but it's probably
harder than just locating the correct spot in the makefile/configury.
This is because tcl and tk can by dynamically loaded, so changing the
DLL name might require other changes elsewhere in the .c code where
"lib" is assumed. I know this was true for the i* variants, but Yaakov
did the work there IIRC.
[2] No, it can't. Creating a tcltk package that contains only the
non-conflicting runtime files (that is, removing from the original tcltk
package the following):
usr/bin/tclsh.exe
usr/bin/wish.exe
usr/include/*.h
usr/lib/*.a
usr/lib/tclConfig.sh
usr/lib/tkConfig.sh
usr/man/mann/*
usr/share/iwidgets4.0.1/demos/*
usr/share/man/mann/*
usr/share/tk8.4/demos/*
doesn't seem to help insight. It launches (rather than dying due to
missing DLL), but then complains because it finds itcl-3.4 (the new X
version) and wants exactly itcl-3.2. I don't know why it is not locating
the itcl-3.2 package, which is right where it always was at
/usr/[lib|share]/itcl3.2/. Maybe tcl is smart, and seeing:
/usr/lib/itcl3.2/pkgIndex.tcl
/usr/lib/itcl3.4/pkgIndex.tcl
it loads always the newest one. Well, that's a bust. But, gitk works
as-is with both the new X-based wish8.5.exe and the old wish84.exe; I
just have to change the 'exec wish' (or modify the /usr/bin/wish
symlink) two switch between them. However, I begin to suspect that it
will be much more trouble than it is worth to keep a backward-compatible
version of tcltk(8.4) around. If tcltk8.4 requires recompilation to
change its extension search path so as not to be confused by the "new"
extensions that are compatible only with the new tcl and tk -- and this
recompilation may then require additional recompilation of the dependent
projects (python, ruby, etc) -- have we really gained anything? If we
have to recompile the dependent projects anway...might as well have 'em
use the 8.5-series (assuming that accepting the X11 requirement is still
ok, across the board).
Anyhoo, with the packages above installed, and the attached patch
against a source tree created by:
$ cvs -d:pserver:anon...@sourceware.org:/cvs/src co insight
$ cd src
$ rm -rf itcl
$ rm -rf tcl
$ rm -rf tk
$ <apply patch>
$ cd ..
The following build recipe seems to work:
$ mkdir _build
$ mkdir _inst && cd _inst && instdir=`pwd` && cd ..
$ cd _build
$ ../src/configure \
--prefix=/usr --sysconfdir=/etc --localstatedir=/var \
--enable-gdbtk --with-curses --with-libiconv-prefix=/usr \
--with-tcl=/usr/lib/tcl8.5 \
--with-tk=/usr/lib/tk8.5 \
--with-x \
--disable-werror # optional: --with-python [3]
$ make all-gdb info
$ make install install-libgui DESTDIR=${instdir}
I get gdb.exe, insight.exe, and gdbtui.exe which each weigh in at 20MB.
Unfortunately, using this build recipe, the gdb.exe and gdbtui.exe you
get have dependencies on the X libraries even if they don't actually use
them.
Turning the result into a cygwin-compliant installation package -- such
as removing files that conflict with the binutils package from the
installation tree, "splitting" into a gdb(no-x) and an insight package
(where presumably the former is the product of an entirely separate
configure/compile process) etc -- is left as an exercise. It works
in-place, tho -- so adding _inst/usr/bin to the front of PATH is fine.
[3] but only if you've also already rebuilt python with the new X-based tk.
> I'm really thinking that insight should be retired. I know the maintainer
> pretty well and he's not extremely keen on keeping it its current
> state.
Keith said:
http://sources.redhat.com/ml/insight/2009-q3/msg00035.html
that Insight 7.0 will be the last release of that codebase. He's also
said that he has dreams of one day rewriting a gui debugger based on
newer gdb facilities (with python? pyGTK?)
http://sourceware.org/gdb/wiki/PythonGdb
"It should be possible to rewrite Insight in Python."
But that's quite a lot of effort, and I don't see anybody jumping up and
down to get that done soon.
OTOH...there do already exist several other FOSS GDB front-ends that are
somewhat usable on cygwin/windows: there's
1) the Zylin Eclipse/CDT plugin, for "standalone" debugging. This has
nothing to do with cygwin, except that it can be used with cygwin's gdb
as the back end. It knows how to exploit cygpath to DTRT, since it
doesn't understand posix paths itself, being a native application.
2) Then you've got the KDE-based kdevelop, which is already ported to
cygwin/X over at the cygwin-ports project. I don't know how many
cygwin-ports (as opposed to stock cygwin) dependencies it has.
3) Cygwin-ports also has a version of the Gnome-based Anjuta. I don't
know how many cygwin-ports (as opposed to stock cygwin) dependencies it has.
4) And nemiver could probably also be ported, given our existing (stock
cygwin) GTK infrastructure...this might be the most lightweight approach
for a semi-official cygwin GDB frontend, but it's also the least mature.
(plus DDD, and Emacs GDB-mode)
As an aside, 'gdbtui' is kinda neat; I'd never used that before even
though it has long been part of cgf's gdb packages.
--
Chuck
Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1099
diff -u -p -r1.1099 Makefile.in
--- gdb/Makefile.in 15 Sep 2009 16:09:31 -0000 1.1099
+++ gdb/Makefile.in 16 Sep 2009 11:23:15 -0000
@@ -167,7 +167,7 @@ TARGET_SYSTEM_ROOT = @TARGET_SYSTEM_ROOT
TARGET_SYSTEM_ROOT_DEFINE = @TARGET_SYSTEM_ROOT_DEFINE@
# Did the user give us a --with-gdb-datadir option?
-GDB_DATADIR_PATH = @GDB_DATADIR_PATH@
+GDB_DATADIR = @GDB_DATADIR@
# Helper code from gnulib.
LIBGNU = gnulib/libgnu.a
@@ -899,13 +899,13 @@ xml-syscall-copy:
.PHONY: xml-syscall-install
xml-syscall-install:
$(SHELL) $(srcdir)/../mkinstalldirs \
- $(DESTDIR)$(GDB_DATADIR_PATH)/$(XML_SYSCALLS_DIR) ; \
+ $(DESTDIR)$(GDB_DATADIR)/$(XML_SYSCALLS_DIR) ; \
list='$(XML_SYSCALLS_FILES)' ; \
for file in $$list ; do \
f=$(srcdir)/$(XML_SYSCALLS_DIR)/$$file ; \
if test -f $$f ; then \
$(INSTALL_DATA) $$f \
- $(DESTDIR)$(GDB_DATADIR_PATH)/$(XML_SYSCALLS_DIR) ; \
+ $(DESTDIR)$(GDB_DATADIR)/$(XML_SYSCALLS_DIR) ; \
fi ; \
done ;
Index: gdb/configure
===================================================================
RCS file: /cvs/src/src/gdb/configure,v
retrieving revision 1.288
diff -u -p -r1.288 configure
--- gdb/configure 10 Sep 2009 03:59:37 -0000 1.288
+++ gdb/configure 16 Sep 2009 11:23:17 -0000
@@ -13274,7 +13274,7 @@ WIN32LDAPP=
case "${host}" in
-*-*-cygwin* | *-*-mingw* )
+*-*-mingw* )
configdir="win"
;;
*)
Index: gdb/configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.106
diff -u -p -r1.106 configure.ac
--- gdb/configure.ac 10 Sep 2009 03:59:36 -0000 1.106
+++ gdb/configure.ac 16 Sep 2009 11:23:17 -0000
@@ -1662,7 +1662,7 @@ AC_SUBST(WIN32LIBS)
AC_SUBST(WIN32LDAPP)
case "${host}" in
-*-*-cygwin* | *-*-mingw* )
+*-*-mingw* )
configdir="win"
;;
*)
Index: gdb/gdbtk/generic/gdbtk-varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v
retrieving revision 1.23
diff -u -p -r1.23 gdbtk-varobj.c
--- gdb/gdbtk/generic/gdbtk-varobj.c 6 Apr 2009 23:11:10 -0000 1.23
+++ gdb/gdbtk/generic/gdbtk-varobj.c 16 Sep 2009 11:23:17 -0000
@@ -417,10 +417,12 @@ variable_children (Tcl_Interp *interp, s
struct varobj *child;
char *childname;
int ix;
+ int from = -1;
+ int to = -1;
list = Tcl_NewListObj (0, NULL);
- children = varobj_list_children (var);
+ children = varobj_list_children (var, &from, &to);
for (ix = 0; VEC_iterate (varobj_p, children, ix, child); ++ix)
{
Index: gdb/gdbtk/generic/gdbtk.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk.c,v
retrieving revision 1.50
diff -u -p -r1.50 gdbtk.c
--- gdb/gdbtk/generic/gdbtk.c 6 Apr 2009 23:33:32 -0000 1.50
+++ gdb/gdbtk/generic/gdbtk.c 16 Sep 2009 11:23:17 -0000
@@ -60,7 +60,7 @@
#include "gdbcmd.h"
#ifdef __CYGWIN32__
-#include <sys/cygwin.h> /* for cygwin32_attach_handle_to_fd */
+#include <sys/cygwin.h> /* for cygwin_attach_handle_to_fd */
#endif
extern void _initialize_gdbtk (void);
@@ -526,7 +526,7 @@ gdbtk_init (void)
* These are the commands to do some Windows Specific stuff...
*/
-#ifdef __WIN32__
+#if defined(__WIN32__) && !defined(__CYGWIN__)
if (ide_create_messagebox_command (gdbtk_interp) != TCL_OK)
error ("messagebox command initialization failed");
/* On Windows, create a sizebox widget command */
@@ -709,13 +709,13 @@ _initialize_gdbtk ()
break;
default:
AllocConsole ();
- cygwin32_attach_handle_to_fd ("/dev/conin", 0,
+ cygwin_attach_handle_to_fd ("/dev/conin", 0,
GetStdHandle (STD_INPUT_HANDLE),
1, GENERIC_READ);
- cygwin32_attach_handle_to_fd ("/dev/conout", 1,
+ cygwin_attach_handle_to_fd ("/dev/conout", 1,
GetStdHandle (STD_OUTPUT_HANDLE),
0, GENERIC_WRITE);
- cygwin32_attach_handle_to_fd ("/dev/conout", 2,
+ cygwin_attach_handle_to_fd ("/dev/conout", 2,
GetStdHandle (STD_ERROR_HANDLE),
0, GENERIC_WRITE);
break;
Index: gdb/gdbtk/plugins/Make-rules
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/plugins/Make-rules,v
retrieving revision 1.3
diff -u -p -r1.3 Make-rules
--- gdb/gdbtk/plugins/Make-rules 2 Aug 2008 22:08:32 -0000 1.3
+++ gdb/gdbtk/plugins/Make-rules 16 Sep 2009 11:23:17 -0000
@@ -35,7 +35,7 @@ TCL_SHLIB_CFLAGS = @TCL_SHLIB_CFLAGS@
TCL_SHLIB_LD = @TCL_SHLIB_LD@
TCL_DBGX = @TCL_DBGX@
TCL_SHLIB_SUFFIX = @TCL_SHLIB_SUFFIX@
-TCL_INCLUDES = @TCL_INCLUDES@
+TCL_INCLUDES = @TCL_INCLUDES@ -I@TCL_SRC_DIR@/generic
TCL_LIBRARY = @TCL_LIBRARY@
mkinstalldirs = $(srcdir)/../../../../mkinstalldirs
Index: gdb/gdbtk/plugins/configure
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/plugins/configure,v
retrieving revision 1.5
diff -u -p -r1.5 configure
--- gdb/gdbtk/plugins/configure 2 Feb 2009 23:18:06 -0000 1.5
+++ gdb/gdbtk/plugins/configure 16 Sep 2009 11:23:19 -0000
@@ -3325,61 +3325,6 @@ fi
# Since we're not using autoconf > 2.1x, we cannot use AC_CONFIG_FILES.
make_subdirs=""
-# See if -mwin32 works for cygwin
-case "${host}" in
- *cygwin*)
- ocflags=${CFLAGS}
- CFLAGS="${CFLAGS} -mwin32"
-
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-int
-main ()
-{
-
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext
-if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
- (eval $ac_compile) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest.$ac_objext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- :
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-CFLAGS="${ocflags}"
-fi
-rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
- ;;
- *) ;;
-esac
-
# note toplevel plugin build directory
plugin_builddir=`pwd`
Index: gdb/gdbtk/plugins/configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/plugins/configure.ac,v
retrieving revision 1.2
diff -u -p -r1.2 configure.ac
--- gdb/gdbtk/plugins/configure.ac 2 Aug 2008 22:08:32 -0000 1.2
+++ gdb/gdbtk/plugins/configure.ac 16 Sep 2009 11:23:19 -0000
@@ -47,16 +47,6 @@ AC_SUBST(TCL_SHLIB_SUFFIX)
# Since we're not using autoconf > 2.1x, we cannot use AC_CONFIG_FILES.
make_subdirs=""
-# See if -mwin32 works for cygwin
-case "${host}" in
- *cygwin*)
- ocflags=${CFLAGS}
- CFLAGS="${CFLAGS} -mwin32"
- AC_TRY_COMPILE(,,,CFLAGS="${ocflags}")
- ;;
- *) ;;
-esac
-
# note toplevel plugin build directory
plugin_builddir=`pwd`
Index: gdb/gdbtk/plugins/rhabout/rhabout.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/plugins/rhabout/rhabout.c,v
retrieving revision 1.2
diff -u -p -r1.2 rhabout.c
--- gdb/gdbtk/plugins/rhabout/rhabout.c 8 Dec 2004 20:21:08 -0000 1.2
+++ gdb/gdbtk/plugins/rhabout/rhabout.c 16 Sep 2009 11:23:19 -0000
@@ -1,5 +1,12 @@
/* Sample command procedure library for a plug-in. */
+/* quick and dirty hack since DEFS are not passed down
+ * to this level.
+ */
+#if defined(__CYGWIN__) && !defined(HAVE_UNISTD_H)
+#define HAVE_UNISTD_H
+#endif
+
/* You have to include the Tcl headers, of course. */
#include <tcl.h>
Index: libgui/configure
===================================================================
RCS file: /cvs/src/src/libgui/configure,v
retrieving revision 1.19
diff -u -p -r1.19 configure
--- libgui/configure 2 Aug 2008 23:33:36 -0000 1.19
+++ libgui/configure 16 Sep 2009 11:23:23 -0000
@@ -4416,22 +4416,6 @@ if test x$ide_cv_os_cygwin32 = xyes; the
ac_win_build="yes"
fi
-case "${host}" in
-*-*-cygwin*)
- touch ac$$.c
- if ${CC} -c -mwin32 ac$$.c >/dev/null 2>&1; then
- case "$LIBGUI_CFLAGS" in
- *-mwin32*) ;;
- *) LIBGUI_CFLAGS="-mwin32 $LIBGUI_CFLAGS" ;;
- esac
- fi
- rm -f ac$$.o ac$$.c
- ;;
-esac
-case "${host}" in
-*-*-cygwin*)
- LIBGUI_CFLAGS="-DWIN32 $LIBGUI_CFLAGS" ;;
-esac
tmp="`cd $srcdir/library; pwd`"
Index: libgui/configure.ac
===================================================================
RCS file: /cvs/src/src/libgui/configure.ac,v
retrieving revision 1.4
diff -u -p -r1.4 configure.ac
--- libgui/configure.ac 2 Aug 2008 23:33:36 -0000 1.4
+++ libgui/configure.ac 16 Sep 2009 11:23:23 -0000
@@ -51,23 +51,6 @@ ac_win_build="no"
if test x$ide_cv_os_cygwin32 = xyes; then
ac_win_build="yes"
fi
-
-case "${host}" in
-*-*-cygwin*)
- touch ac$$.c
- if ${CC} -c -mwin32 ac$$.c >/dev/null 2>&1; then
- case "$LIBGUI_CFLAGS" in
- *-mwin32*) ;;
- *) LIBGUI_CFLAGS="-mwin32 $LIBGUI_CFLAGS" ;;
- esac
- fi
- rm -f ac$$.o ac$$.c
- ;;
-esac
-case "${host}" in
-*-*-cygwin*)
- LIBGUI_CFLAGS="-DWIN32 $LIBGUI_CFLAGS" ;;
-esac
AC_SUBST(LIBGUI_CFLAGS)
tmp="`cd $srcdir/library; pwd`"
Index: libgui/src/tclshellexe.c
===================================================================
RCS file: /cvs/src/src/libgui/src/tclshellexe.c,v
retrieving revision 1.2
diff -u -p -r1.2 tclshellexe.c
--- libgui/src/tclshellexe.c 8 Sep 2001 22:34:47 -0000 1.2
+++ libgui/src/tclshellexe.c 16 Sep 2009 11:23:23 -0000
@@ -3,7 +3,7 @@
Written by Tom Tromey <tromey@cygnus.com>;
Code mostly taken from S-N. */
-#ifdef _WIN32
+#if defined(_WIN32) || defined(__CYGWIN__)
#include <string.h>
--
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
