Re: [HEADSUP] Moving setup sources to git

[Vin Shelton]

I thought I would give this a go, to see how the documentation works
for me, but no joy:

On Tue, Feb 10, 2015 at 3:31 AM, Corinna Vinschen wrote:
 git clone cygwin.com:/git/cygwin-setup.git setup

git clone cygwin.com:/git/cygwin-setup.git
Cloning into 'cygwin-setup'...
Permission denied.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Regards,
  Vin Shelton

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Volker -
On Fri, Jan 30, 2015 at 10:51 AM, Dr. Volker Zell wrote:
 I downloaded the latest version 21.4.23 and tried to build it, but I 
 consistently get:

 gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration 
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2
  
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2
   -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c
 gcc -ggdb -O2 -pipe -Wimplicit-function-declaration 
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2
  
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2
  -o xemacs  abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o 
 callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o 
 console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o 
 elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o 
 menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o 
 event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o 
 glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o 
 postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o 
 menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o 
 mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o 
 inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o 
 objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o 
 process-unix.o event-stream.o extents.o faces.o fileio.o  filemode.o 
 floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o 
 glyphs-widget.o gui.o gutter.o  hash.o imgproc.o indent.o insdel.o intl.o 
 keymap.o  line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o 
 objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o 
 redisplay-output.o regex.o search.o select.o  signal.o sound.o specifier.o 
 strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o 
 event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o 
 xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o 
 vm-limit.o  EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o 
 TransientEmacsShell.o EmacsManager.o  offix.o dump-id.o ../lwlib/liblw.a  
 -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt 
 -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm 
 -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool
 collect2: error: ld terminated with signal 11 [Segmentation fault], core 
 dumped
 GNUmakefile:159: recipe for target 'xemacs' failed
 make[1]: *** [xemacs] Error 1
 make[1]: Leaving directory 
 '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src'
 GNUmakefile:123: recipe for target 'src' failed
 make: *** [src] Error 2
  [1;31m*** ERROR: [0;0m make failed


 After the ld core dump, when I delete the corrupted xemacs.exe from
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually
 and restart the build with make from the
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory
 again, the build actually succeeds and ld doesn't core dump
 anymore.

I don't see this segfault.  I am running the default version of gcc,
and I assume you are, too.  Perhaps you need to rebaseall?

Your build path is ...xemacs-21.4.22... are you sure you're using
21.4.23 sources?

 Additionally I had to use an older version of texinfo (namely
 version 4.13) otherwise the build breaks when generating the .info files
 (I got the information to use an older version from Vin Shelton).

Yes, the texinfo incompatibilities is one reason I want to EOL 21.4.
An alternative approach for Cygwin would be to patch the .texi sources
to work with newer texinfos.


 I then installed everything and with my current setup xemacs crashed as
 soon as font-locking is involved. The current 32 bit xemacs-21.4.22
 version works fine with this setup. After googling around I found a
 workaround by setting (setq progress-feedback-use-echo-area t) in my
 .emacs.

This error should be fixed in 21.4.23, there's a new
configure.in/configure designed to prevent this.  Again - are you sure
you're using 21.4.23?

 So, the good news finally after 6 years !!! it seems I have a working
 xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do
 more testing.

 The bad news, an automatic build via cygport is currently not possible 
 because:

 1. cygport's compile stage bails out after the ld core dump
 2. the current xemacs version needs an older version of texinfo (4.13)
than we have currently in the distribution (5.2-3)

 Question: How shall I proceed ?


  - Vin

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote:
 On Jan 28 22:32, Vin Shelton wrote:
 I think I have verified this behavior - I restored the old sysdep.c
 module and moved the disconnect_controlling_terminal() call [which
 calls setsid()] from right after the fork() to just before the exec()
 call and M-x shell works on Cygwin as it always has on linux.

 Good news!  So the XEmacs code is in a state now that Volker can
 start creating a Cygwin package?

Yes, the 21.4 code in the hg repository builds and runs on Cygwin.

Regards,
  Vin

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Hi, Corinna et al,

On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
 On Jan 27 23:05, Vin Shelton wrote:
 I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
 Here's what I found out.

 In the child after fork() but before exec(), the setsid() call in
 disconnect_controlling_terminal() is causing the subprocess not to
 function after it gets spawned.

 Can you define not function a bit more detailed?  Does no process work
 at all, or do only processes requiring a tty not work?  For instance,
 does something like an echo foo  bar still work?

M-x shell is specifically designed to spawn an interactive process
like a shell.  The bash subprocess starts, but it accepts no input.
Here is the output of ps for that process:

S1740 2521740268  pty11003 08:10:54 /usr/bin/bash

I think it's only commands requiring a tty, but that's the whole point
of M-x shell mode.  There is a separate command - M-x shell-command -
which is designed to run and capture the output of individual commands
like ls or echo.  That works fine.

BTW, if I try to spawn gdb as a shell, the behavior is similar, but
this time the process looks like this:

 332832483328   3408  pty21003 08:15:18
/usr/bin/gdb defunct

HTH.


 Thanks for any insight you can offer.

 Hmm, not off the top of my head.  Is there a chance that you could
 provide a simple, self contained testcase to reproduce the setsid
 behaviour?  I think I have to debug that.

You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)

I'll try.  Meanwhile, I've been looking at the emacs code (which in
this case is simpler) to see if I can figure out how it is that M-x
shell works there.

Thank you!

  - Vin

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Dear Corinna, et al -

On Wed, Jan 28, 2015 at 8:58 AM, Corinna Vinschen wrote:
 On Jan 28 08:20, Vin Shelton wrote:
 On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
  On Jan 27 23:05, Vin Shelton wrote:
  I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
  Here's what I found out.
 
  In the child after fork() but before exec(), the setsid() call in
  disconnect_controlling_terminal() is causing the subprocess not to
  function after it gets spawned.
 
  Can you define not function a bit more detailed?  Does no process work
  at all, or do only processes requiring a tty not work?  For instance,
  does something like an echo foo  bar still work?

 M-x shell is specifically designed to spawn an interactive process
 like a shell.  The bash subprocess starts, but it accepts no input.
 Here is the output of ps for that process:

 S1740 2521740268  pty11003 08:10:54 /usr/bin/bash

 I think it's only commands requiring a tty, but that's the whole point
 of M-x shell mode.  There is a separate command - M-x shell-command -
 which is designed to run and capture the output of individual commands
 like ls or echo.  That works fine.

 BTW, if I try to spawn gdb as a shell, the behavior is similar, but
 this time the process looks like this:

  332832483328   3408  pty21003 08:15:18
 /usr/bin/gdb defunct

 HTH.

 
  Thanks for any insight you can offer.
 
  Hmm, not off the top of my head.  Is there a chance that you could
  provide a simple, self contained testcase to reproduce the setsid
  behaviour?  I think I have to debug that.

 You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)

 LOL.

After thinking about this for awhile, it dawned on me that the problem
is not with setsid() per se, but rather with the sequence of events
_following_ the setsid() call.  That is, setsid() causes some of the
ensuing ioctl() (or similar) calls that set up the pty to fail.

I think I have verified this behavior - I restored the old sysdep.c
module and moved the disconnect_controlling_terminal() call [which
calls setsid()] from right after the fork() to just before the exec()
call and M-x shell works on Cygwin as it always has on linux.

I will endeavor to create a STC for Cygwin that includes all the code
involved in setting up the terminal so we can experiment with moving
the setsid() call between the beginning and the end of the function.

  - Vin

Cygwin Subprocesses on XEmacs

[Vin Shelton]

I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
Here's what I found out.

In the child after fork() but before exec(), the setsid() call in
disconnect_controlling_terminal() is causing the subprocess not to
function after it gets spawned.

Here is a patch which works around the problem, enabling M-x shell to
work for bash and zsh (at least):

diff -r 00f2705e2cb3 src/sysdep.c
--- a/src/sysdep.c Mon Jan 26 08:53:07 2015 -0500
+++ b/src/sysdep.c Tue Jan 27 22:15:16 2015 -0500
@@ -1319,7 +1319,7 @@
 void
 disconnect_controlling_terminal (void)
 {
-#  ifdef HAVE_SETSID
+#  if defined(HAVE_SETSID)  !defined(CYGWIN)
   /* Controlling terminals are attached to a session.
  Create a new session for us; it will have no controlling
  terminal.  This also, of course, puts us in our own


HOWEVER - I don't understand why this should be necessary.


I here reproduce all of disconnect_controlling_terminal() for your
reading pleasure.

void
disconnect_controlling_terminal (void)
{
#  if defined(HAVE_SETSID)  !defined(CYGWIN)
  /* Controlling terminals are attached to a session.
 Create a new session for us; it will have no controlling
 terminal.  This also, of course, puts us in our own
 process group. */
  setsid ();
#  else
  /* Put us in our own process group. */
  EMACS_SEPARATE_PROCESS_GROUP ();
#if defined (TIOCNOTTY)
  /* This is the older way of disconnecting the controlling
 terminal, on 4.3 BSD.  We must open /dev/tty; using
 filedesc 0 is not sufficient because it could be
 something else (e.g. our stdin was redirected to
 another terminal).
 */
  {
int j = open (/dev/tty, O_RDWR, 0);
ioctl (j, TIOCNOTTY, 0);
close (j);
  }
#endif /* TIOCNOTTY */
  /*
 On systems without TIOCNOTTY and without
 setsid(), we don't need to do anything more to
 disconnect our controlling terminal.  Here is
 what the man page for termio(7) from a SYSV 3.2
 system says:

 The first terminal file opened by the process group leader
 of a terminal file not already associated with a process
 group becomes the control terminal for that process group.
 The control terminal plays a special role in handling quit
 and interrupt signals, as discussed below.  The control
 terminal is inherited by a child process during a fork(2).
 A process can break this association by changing its process
 group using setpgrp(2).

 */
#  endif /* not HAVE_SETSID */
}


Since Cygwin doesn't seem to have TIOCNOTTY, commenting out the
setsid() call reduces disconnect_controlling_terminal to:

void
disconnect_controlling_terminal (void)
{
# 1330 sysdep.c
  setpgid (0, 0);
# 1362 sysdep.c
}

Incidentally, that setpgid() call causes bash to complain at startup:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Thanks for any insight you can offer.

  - Vin

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Dear Volker, Ken and Corinna,

On Fri, Jan 23, 2015 at 10:43 AM, Dr. Volker Zell wrote:
 Ken Brown writes:

  On 1/23/2015 5:57 AM, Dr. Volker Zell wrote:
  gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration 
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2
  
 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2
   -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves 
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c
  In file included from 
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
  
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16:
  error: expected ';', ',' or ')' before 'int'
  #define Status int
  ^
  In file included from /usr/include/w32api/rpc.h:74:0,
  from /usr/include/w32api/objbase.h:7,
  from /usr/include/w32api/ole2.h:17,
  from /usr/include/w32api/shlobj.h:85,
  from 
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77,
  from 
 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:
  /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 
 'RPC_OBJECT_INQ_FN'
  RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN 
 *InquiryFn);

  I think the problem is that Status is used in 
 /usr/include/w32api/rpcdce.h,
  and this conflicts with #define Status int.  I ran into a similar 
 problem when
  trying to build clisp.

 Any simple fix/workaround  for this ?

Thanks for pointing this out.  It dawned on me yesterday that the
reason I didn't see these problems is because I don't build with X
support on Cygwin.  Once I configured in X support, I saw these errors
and a few others.  It took me awhile to work out the right changes to
make, but I have checked changes into the XEmacs 21.4 mercurial
repository that enable XEmacs 21.4 to build under Cygwin with X
support.

One problem remains - Xaw3d support does not work, so I removed that
from the configure line.  The problem I found was that XEmacs seemed
to be expecting version 8 of Xaw3d, but Cygwin supplies version 7.

I still plan to release 21.4.23 in the near future, but I would
recommend making an updated XEmacs 21.4 kit before that point.

Regards,
  Vin Shelton

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Hi, Volker -

Vin wrote:
 I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

Volker wrote:
 Here we are

A few thoughts:

1. You need to use the most recent XEmacs sources from mercurial.

2. You must have an old version of libpng installed, because 21.4.22
won't compile with the newer libpng (some structure members are
hidden).

3. You will also need to add:

#define stricmp strcasecmp

to src/s/cygwin32.h

4. I will review the contents of xemacs-21.4.22-1.src.patch and
promote at least your developer info and the above stricmp hack to the
mercurial repo.

5. I have promised to release 21.4.23, so I will do that shortly after #4 above.

  - Vin

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Volker -

I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

Thanks,
  Vin Shelton


On Thu, Jan 15, 2015 at 6:27 AM, Dr. Volker Zell
dr.volker.z...@oracle.com wrote:
 David Stacey writes:

  On 14/01/15 14:13, Corinna Vinschen wrote:
  The following packages have dependecies of their own, so they can't
  go away until the dependent packages have been rebuilt:
 
  libpqMarco Atzeri
 
  required by:
 
  xemacs   Dr. Volker Zell

  Some time ago, there was a problem rebuilding xemacs [1]. Is this still 
 an issue?

 It used to compile but was not usable because of broken subprocess
 support. Now it doesn't even compile :-(

  Dave.

 Ciao
   Volker

Re: [HEADSUP] Dropping libopenssl098 from distro

[Vin Shelton]

Marco/Volker et al -

On Thu, Jan 15, 2015 at 7:50 AM, Marco Atzeri marco.atz...@gmail.com wrote:
 On 1/15/2015 1:31 PM, Vin Shelton wrote:


 It used to compile but was not usable because of broken subprocess
 support. Now it doesn't even compile :-(
 Ciao
Volker


 Volker -

 I can build XEmacs on 32-bit Cygwin.  What doesn't work for you?

 Thanks,
Vin Shelton


 Question:
 0) does it work ?

Yes.  I am the XEmacs stable (21.4) build maintainer and make the
native Windows setup kits (both 21.4 and 21.5) for XEmacs, but I don't
use Windows very much these days.

 1) configure parameters ?

Well, that's why I asked Volker what problems he had - it's easier to
solve problems when you have a description of them.

Here is the Installation file from my most recent cygwin build of XEmacs 21.5:

uname -a: CYGWIN_NT-5.1 legolas-xp3 1.7.33-2(0.280/5/3) 2014-11-13
15:45 i686 Cygwin

../../src/xemacs-21.5-2015-01-10-mule/configure
'--prefix=/usr/local/xemacs-21.5-2015-01-10-mule' '--enable-mule'
'--without-xim' '--enable-bignum=gmp' '--with-dialogs'
'--enable-pdump' '--with-sound=native' '--with-widgets' '--without-x'
'--with-dragndrop' '--with-cflags= -Os -malign-double -pipe
-ffast-math' '--with-default-eol-detection'
'--with-infopath=/usr/local/info'
'--with-package-path=/XEmacs/site-packages::/XEmacs/xemacs-packages'
'--with-site-prefix=' '--without-tls' 'CC=gcc' 'CFLAGS=-Os
-malign-double -pipe -ffast-math'


XEmacs 21.5-b34 kale  configured for `i686-pc-cygwin'.

Compilation Environment and Installation Defaults:
  Source code location:  /usr/local/src/xemacs-21.5-2015-01-10-mule
  Installation prefix:   /usr/local/xemacs-21.5-2015-01-10-mule
  Operating system description file: `s/cygwin32.h'
  Machine description file:  `m/intel386.h'
  Compiler version:  gcc (GCC) 4.9.2
- GCC specs file:specs.
- Compiler command:  gcc -I/usr/include/noX
-I/usr/include/noX -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wpointer-arith -Wshadow
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes
-Wdeclaration-after-statement  -Wunused-parameter -g   -Os
-malign-double -pipe -ffast-math
  libc version:
  Relocating allocator for buffers:  no
  GNU version of malloc: yes

Package Search (a 'root' contains '{xemacs,mule,site}-packages'):
  User package roots:~/.xemacs
  System package roots:  /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs
WARNING: /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs was
specified, but doesn't exist.
WARNING: XEmacs functionality will be noticably limited until
WARNING: some packages are installed.

Window System:
  Compiling in support for the Microsoft window system.
  Using MS-Windows menubars.
  Using MS-Windows scrollbars.
  Using MS-Windows dialog boxes.
  Using MS-Windows native widgets.
  Compiling in support for Drag'n'Drop (EXPERIMENTAL).
-  Drag'n'Drop prototype:  msw.

TTY:

Images:
  Compiling in support for XPM  images.
  Compiling in support for PNG  images.
  Compiling in support for JPEG images.

Sound:
  Compiling in support for sound (native).

Databases:

Internationalization:
  Compiling in support for Mule (multi-lingual Emacs).

Mail:
  Compiling in support for POP mail retrieval.

Network:
  Inhibiting IPv6 canonicalization at startup.

Other Features:
  Compiling in support for dynamic shared object modules.
  Compiling in support for more number types using the GNU MP library.
  Using the new GC mark algorithms (KKCC).
  WARNING: -
  WARNING: The new algorithms are experimental. They are enabled by
  WARNING: default for this release. Use `--disable-kkcc' to
  WARNING: turn it off.
  WARNING: -
  Using the new portable dumper.
  Dumping into executable.
  Compiling in support for extra debugging code.
  Compiling in support for runtime error checking.
  WARNING: -
  WARNING: XEmacs will run noticeably more slowly as a result.
  WARNING: Error checking is on by default for XEmacs beta releases.
  WARNING: -


 2) have you tried a 64 build also ?

No, but based on feedback from the xemacs-beta mailing list, I do not
believe that 64-bit mode currently builds.

Regards,
  Vin

Re: I broke cygport

[Vin Shelton]

Thanks for your feedback.

Yaakov S (Cygwin Ports) wrote:

cygconf is intended only for autoconf-based configure scripts.  I'm not
familiar with XEmacs, but I do know that autoconf-based configures will
just ignore unknown arguments, so I will guess that XEmacs' configure is
not autoconf-based.


Well XEmacs 21.4 is based on autoconf 2.13 and 21.5 is based on autoconf
2.59.  Neither configure script ignores unknown arguments:

$ ../cvsroot/xemacs-21.4/configure --datarootdir=/foo
../cvsroot/xemacs-21.4/configure: Usage error:
  Unrecognized option: --datarootdir=/foo
  Use `../cvsroot/xemacs-21.4/configure --help' to show usage.

$ ../cvsroot/xemacs-21.5/configure --datarootdir=/foo
configure: error: unrecognized option: --datarootdir=/foo
Try `../cvsroot/xemacs-21.5/configure --help' for more information.



Non-autoconf-based configure scripts should do something like:

lndirs
cd ${B}
./configure args || error configure failed
cygmake


Fair enough.

For the record, attached is a patch against CVS head.  This patch
allows overriding the individual components of the default configure
arguments in the cygconf() function.  In addition, I fixed some minor
typos in README unrelated to the cygconf() change; you may find those
useful in their own right.

BTW, your ChangeLog format is different from what I'm used to; I'm used to
including an identifier of who made the change.  See
http://www.gnu.org/prep/standards/html_node/Change-Logs.html for details.

Thanks again for cygport.

Regards,
  Vin Shelton


--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771poem=30506


cygport2.diffs
Description: Binary data