Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
Verse X wrote: I'm new to this mailing list, and don't undertand what's going on here. Your question is on the wrong list. This belongs on the main cygwin list. Just FYI, all messages on all lists are archived at http://cygwin.com/ml/ so you can read the past context of threads that you may have missed. C:\cygwin\usr\sbin\lighttpd.exe (1072): *** unable to remap C:\cygwin\lib\lighttpd\mod_indexfile.dll to same address as parent(0x3F) != 0x97 9 [main] lighttpd 2224 fork_parent: child 1072 died waiting for dll loading This just means that you need to install the rebase package and run the rebaseall procedure that is described in /usr/share/doc/Cygwin/rebase-*.README. Brian
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
2006/1/12, Brian Dessent [EMAIL PROTECTED]: C:\cygwin\usr\sbin\lighttpd.exe (1072): *** unable to remap C:\cygwin\lib\lighttpd\mod_indexfile.dll to same address as parent(0x3F) != 0x97 9 [main] lighttpd 2224 fork_parent: child 1072 died waiting for dll loading Mhh, anyway, if --enable-auto-base is an all-win option (it is never worse than a constant address, is it?) why don't we proposre it for default LDFLAGS in the gbs? That way, we can avoid most of such messages, as far as I undersood (?) Lapo -- Lapo Luchini [EMAIL PROTECTED]
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lapo Luchini wrote: Mhh, anyway, if --enable-auto-base is an all-win option (it is never worse than a constant address, is it?) why don't we proposre it for default LDFLAGS in the gbs? That way, we can avoid most of such messages, as far as I undersood (?) If you run autoreconf before configure to pull in the current Cygwin libtool (which I always do and recommend), then that will take care of it. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxpRjpiWmPGlmQSMRAoloAJ9Ju/H6OHb0H+qMHJqOHJnImBMgHACg5Z9s aghL2YXer3OWn5+cbFywVrk= =5hZa -END PGP SIGNATURE-
[Patch] setup source page should use command-line option over last selected
Setup.exe currently (based on CVS HEAD) uses the last selected option from the Source page instead of the command line option (if it is present). For example, if the user selected Download without installing the last time they ran setup, then that will be selected the next time setup runs regardless of the command line. To reproduce: 1) Run 'setup.exe' and on the Choose Download Source page, select (for example) Download without installing. Click next, then cancel. 2) Run 'setup.exe -L' and go to the Choose Download Source page. Install from local directory should be selected, but Download without installing still is. The attached patch should fix this. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] setup.patch Description: setup.patch
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
2006/1/12, Yaakov S (Cygwin Ports) [EMAIL PROTECTED]: If you run autoreconf before configure to pull in the current Cygwin libtool (which I always do and recommend), then that will take care of it. I don't like when a patch doubles the size of the source package all by itself, for this release I'd rather use the one-liner patch of adding --enable-auto-image-base to LDFLAGS and then ask upstream to update libtool so that next release doesn't have the problem to begin with. -- Lapo Luchini [EMAIL PROTECTED]
Please upload: nfs-server-2.3-4
This release corrects a problem with trying to assign to a reserved shell variable in the nfs-server-config script. Hint: http://www.oneparticularharbor.net/cygwin/nfs-server/setup.hint Bin : http://www.oneparticularharbor.net/cygwin/nfs-server/nfs-server-2.3-4.tar.bz2 Src : http://www.oneparticularharbor.net/cygwin/nfs-server/nfs-server-2.3-4-src.tar.bz2 -Samrobb
Re: Please upload: nfs-server-2.3-4
On Thu, Jan 12, 2006 at 03:26:17PM -0500, Robb, Sam wrote: Hint: http://www.oneparticularharbor.net/cygwin/nfs-server/setup.hint Bin : http://www.oneparticularharbor.net/cygwin/nfs-server/nfs-server-2.3-4.tar.bz2 Src : http://www.oneparticularharbor.net/cygwin/nfs-server/nfs-server-2.3-4-src.tar.bz2 Uploaded. cgf
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lapo Luchini wrote:
I don't like when a patch doubles the size of the source package all
by itself, for this release I'd rather use the one-liner patch of
adding --enable-auto-image-base to LDFLAGS
Apparently, setting both '-Wl,--enable-auto-image-base' (via LDFLAGS)
and '-Wl,--image-base=0x100' (from libtool) won't help, quoting from
ld(1) manpage:
- --enable-auto-image-base
Automatically choose the image base for DLLs, unless one is
specified using the --image-base argument. By using a hash
generated from the dllname to create unique image bases for each
DLL, in-memory collisions and relocations which can delay program
execution are avoided. [This option is specific to the i386 PE
targeted port of the linker]
I've been running autoreconf as part of the build process for a long
time with hundreds of packages, and I've been very pleased with it, and
my current .patch files are still minimal.
To prevent a 1MB patch, fix the mkpatch function in the g-b-s. I use
something similar to this:
diff -urN -x '.build' -x '.inst' -x '.sinst' -x 'configure' \
- -x 'Makefile.in*' -x 'aclocal.m4*' -x 'ltmain.sh' -x 'config.*' \
- -x 'depcomp' -x 'install-sh' -x 'missing' -x 'mkinstalldirs' \
- -x 'intltool*' -x 'autom4te.cache' -x '*compile' \
- -x 'COPYING' -x 'INSTALL' \
${P}-orig ${P} ${srcinstdir}/${src_patch_name} ;
and then ask upstream to update libtool so that next release doesn't
have the problem to begin with.
IIRC there are other Cygwin-specific patches in our libtool/auto*, so I
think it's a good idea anyway.
Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDxsP0piWmPGlmQSMRAncTAKCSaZlFqHvHd+cLjd9j5WrK/xVDCwCfT8bB
BHlLEwfq578ZnGYV4stZR0M=
=Zg0R
-END PGP SIGNATURE-
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2006/1/12, Yaakov S (Cygwin Ports) [EMAIL PROTECTED]: To prevent a 1MB patch, fix the mkpatch function in the g-b-s. I use something similar to this: Mhh. I like that. IIRC there are other Cygwin-specific patches in our libtool/auto*, so I think it's a good idea anyway. That's another good point. Unfortunately autoreconfing lighttpd seems to break configure a bit, I guess it misses some escaping or such things. (stops on line 25564: `PKG_CHECK_MODULES(FAM, gamin = 0.1.0,') I'll produce a -2 package as soon as I have time to look into this issue. PS: how do you inspect a DLL to know its ImageBase? - -- Lapo Luchini [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) iEYEARECAAYFAkPG0ccACgkQaJiCLMjyUvvRigCfaKyKlKjPP3Gxx/2Q+f7eEtFu GOIAn3MGF6ezGdznRgCOJU9tJisFze+l =gBLL -END PGP SIGNATURE-
Re: [ITP] updated: lighttpd-1.4.8-1 [Was: lighttpd on cygwin?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lapo Luchini wrote: Unfortunately autoreconfing lighttpd seems to break configure a bit, I guess it misses some escaping or such things. (stops on line 25564: `PKG_CHECK_MODULES(FAM, gamin = 0.1.0,') Do you have pkgconfig installed? pkg.m4 defines PKG_CHECK_MODULES. PS: how do you inspect a DLL to know its ImageBase? objdump -p /path/to/foo.dll | fgrep ImageBase Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxthipiWmPGlmQSMRAh3+AKDH3U3+x8yg7/iOA4HcrEuxAPxPWwCgz78z Do9E0mNCP24/rCejper6cNQ= =wxR6 -END PGP SIGNATURE-
Please upload: perl-Tk-804.027-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please upload: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Please update the setup.hint as well. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxtrrpiWmPGlmQSMRAtztAKD82oHJoD0rTzqnqPs4cKZPUl8SqwCfcUS0 onIUiWqL7Fz10CfsbRZwHW4= =AYH5 -END PGP SIGNATURE-
Re: Please upload: perl-Tk-804.027-4
On Thu, Jan 12, 2006 at 04:40:43PM -0600, Yaakov S (Cygwin Ports) wrote: ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.027-4.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint Please update the setup.hint as well. Uploaded and once again removed the Perl from the category. cgf
Re: Please upload: perl-Tk-804.027-4
Christopher Faylor wrote: Uploaded and once again removed the Perl from the category. Thanks. Perl is a debian category, as is Python. Yaakov
Re: Please upload: perl-Tk-804.027-4
On Thu, Jan 12, 2006 at 09:21:08PM -0600, Yaakov S (Cygwin Ports) wrote: Christopher Faylor wrote: Uploaded and once again removed the Perl from the category. Thanks. Perl is a debian category, as is Python. But, yet, it is not a Cygwin category. Go figure. cgf
[GTG] Re: [ITP] Numeric-24.2
Yaakov S writes: Python Numeric is used by many other Python modules, including pygtk, and is included with every major Linux distribution. Once approved, AFAIK this should be uploaded under /release/python/. ftp://sunsite.dk/projects/cygwinports/release/python/Numeric/Numeric-24.2-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/python/Numeric/Numeric-24.2-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/python/Numeric/setup.hint category: Python requires: cygwin python sdesc: Numeric Python module ldesc: Numerical Python adds a fast, compact, multidimensional array language facility to Python. Builds fine from source and packaging looks good. GTG Yaakov Ciao Volker
Errors when starting Cygwin/X on Windows XP SP2
Hello, I am getting the following errors when I attempt to start the Cygwin/X system on my Windows XP SP2 machine: xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. Have any other users reported this error? Regards, Joe Myers -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Errors when starting Cygwin/X on Windows XP SP2
Joseph Myers wrote: I am getting the following errors when I attempt to start the Cygwin/X system on my Windows XP SP2 machine: xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. Have any other users reported this error? I haven't seen that error message but it looks like it is a firewall problem: xinit uses a tcp and an udp port (XWin uses a bunch of them). Check if XWin is enabled in the Exceptions list of Windows Firewall. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/doc ChangeLog doctool.c
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-12 11:31:55 Modified files: winsup/doc : ChangeLog doctool.c Log message: * doctool.c (scan_directory): Ignore CVS directories. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.112r2=1.113 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/doctool.c.diff?cvsroot=srcr1=1.2r2=1.3
src/winsup/cygwin environ.cc fhandler.h fhandl ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-12 15:53:51 Modified files: winsup/cygwin : environ.cc fhandler.h fhandler_proc.cc init.cc mmap.cc spawn.cc wincap.cc wincap.h winsup/cygwin/include/cygwin: version.h Log message: * Update copyrights. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/environ.cc.diff?cvsroot=srcr1=1.133r2=1.134 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.281r2=1.282 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_proc.cc.diff?cvsroot=srcr1=1.64r2=1.65 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/init.cc.diff?cvsroot=srcr1=1.62r2=1.63 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srcr1=1.125r2=1.126 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc.diff?cvsroot=srcr1=1.208r2=1.209 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc.diff?cvsroot=srcr1=1.46r2=1.47 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.h.diff?cvsroot=srcr1=1.36r2=1.37 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.220r2=1.221
src/winsup/cygserver ChangeLog Makefile.in win ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-12 16:59:15 Modified files: winsup/cygserver: ChangeLog Makefile.in Added files: winsup/cygserver: wincap.cc wincap.h Log message: * wincap.cc: New file. * wincap.h: New file. * Makefile.in: Accomodate having our own wincap implementation now. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/wincap.cc.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/wincap.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/ChangeLog.diff?cvsroot=srcr1=1.50r2=1.51 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygserver/Makefile.in.diff?cvsroot=srcr1=1.11r2=1.12
src/winsup/doc ChangeLog faq-setup.xml
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-01-13 03:55:23 Modified files: winsup/doc : ChangeLog faq-setup.xml Log message: * faq-setup.xml (faq.setup.setup): Correct URL typo. (faq.setup.snapshots): Clarify. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.113r2=1.114 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/faq-setup.xml.diff?cvsroot=srcr1=1.2r2=1.3
Re: Ignore CVS directories when building documentation
On Jan 11 21:32, Igor Peshansky wrote: * doctool.c (scan_directory): Ignore CVS directories. Thanks, applied. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] Proposed clarification of the snapshot installation FAQ
On 1/11/06, Igor Peshansky wrote: As mentioned in http://cygwin.com/ml/cygwin/2006-01/msg00537.html, here's a patch to the FAQ to clarify the section on installing snapshots. I didn't know whether the various *.texinfo files are still used, so I ported the modifications there as well, just in case. Applied to faq-setup.xml (the texinfo files are no longer used... I suppose I should remove them). It would be nice to have a sample batch file that automated the cygwin1.dll replacement, too.
Re: [PATCH] Proposed clarification of the snapshot installation FAQ
On Thu, 12 Jan 2006, Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:57:27PM -0800, Joshua Daniel Franklin wrote: On 1/11/06, Igor Peshansky wrote: As mentioned in http://cygwin.com/ml/cygwin/2006-01/msg00537.html, here's a patch to the FAQ to clarify the section on installing snapshots. I didn't know whether the various *.texinfo files are still used, so I ported the modifications there as well, just in case. Applied to faq-setup.xml Thanks. (the texinfo files are no longer used... I suppose I should remove them). Yes, please. It would be nice to have a sample batch file that automated the cygwin1.dll replacement, too. I was hoping for a little more discussion about this. I think Corinna and I are both a little despondent over the fact that we have to be SUPER precise about obvious things like when you say something like cd /tmp it means that you should be doing it in a POSIX shell. I have to wonder what kind of useful feedback we'll get from people who can't figure this out. I also was going to caution against telling everyone to try a snapshot at the first hint of trouble. I don't think that this should be used as a panacea, although I realize that the length of time since the last cygwin release has made it attractive. ...but that's not an issue for this mailing list... Right. Nevertheless, the advice about using mv to rename cygwin1.dll won't work on every version of Windows and needs to be changed. Hmm, it's worked for me on Win98, Win2k, and WinXP (though I suppose there could be differences on, say, WinNT4 or something)... I basically wanted to avoid giving too many things to do in Windows Explorer. But no matter -- I'll submit a patch with this change shortly. FWIW, I usually do cd /bin cygstart cmd, and then close the bash shell and do the renaming in the CMD window. However, I don't think this particular set of instructions can rely on the presence of cygstart... I didn't read much else besides that because I was just too depressed by the fact that the current words were quoteconfusing/unquote. Sigh... I'm sure there'll be complaints about my wording too. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac
problems with running Gnome applications
hi everybody. I'd like to have a clue on how can get Gnome and Gtk applications work on cygwin. It would be cool to have a clean and as complete as possible tutorial/wiki with infos about installing Gnome and applicationso n cygwin and make them work. I got many problems with gconfd (errors like this: No database available to save your configuration: Unable to store a value at key '/apps/evince/sidebar_size', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put ORBIIOPIPv4=1 in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf i cant execute bluefish ( Bad system call message) etcetera. I have Win 2003 server and latest Cygwin/Cygwin ports installation. Thanks, Alessandro -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]
Gary R. Van Sickle wrote: From: Dave Korn [snip] I don't get that. I've got the default alternatives set, so IIUIC it should have selected the most recent autoconf, shouldn't it? I imagine this is intended to work with everything in the default installation state, but as you see it certainly doesn't WFM! You use text mounts? ackSPIT Nope. :) cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: problems with running Gnome applications
Alessandro Lendaro wrote: i cant execute bluefish ( Bad system call message) etcetera. This is a http://cygwin.com/acronyms#WAG, but have you got CYGWIN=server set in your environment, and are you running the cygserver? That's a pretty common cause of Bad system call errors. Of course, I would already have known the answer to those two questions if you had sent your cygcheck output as an attachment, like it says at http://cygwin.com/problems.html ! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [ANNOUNCEMENT] Updated: fftw3-3.0.1-2
Chris, My records show I only sent this out once, to the announcements list, and it did not have any [ANNOUNCEMENT] header tacked on to the front of the subject. I am mystified as to how it showed up again, with double header, both on the cygwin and on the announcement list. I would like to say I'll avoid such an error in the future; however in this case it does not appear to me that I made any such error. jrp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
config error with Apache2 package
Hi List, I have here the last version of cygwin and Apache2 package If I make the following: apache2-2.0.54-1.sh conf (after prep) I get the following error message. #-#-#-#-#-#-#-# checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E Configuring PCRE regular expression library ... configuring package in srclib/pcre now configure: error: expected an absolute directory name for --bindir: NONE/bin #-#-#-#-#-#-#-#- Possibly someone an idea? Thank you for each assistance. Stefan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
nfs-server-config died
Hi, When I executed /usr/bin/nfs-server-config, it died around line 223 due to the assignment to readonly variable $UID. Is this a known issue? The version of the package is nfs-server-2.3-3. -- Hiroki Sakagami -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with running Gnome applications
Dave Korn wrote: This is a http://cygwin.com/acronyms#WAG, but have you got CYGWIN=server set in your environment, and are you running the cygserver? That's a pretty common cause of Bad system call errors. Of course, I would already have known the answer to those two questions if you had sent your cygcheck output as an attachment, like it says at http://cygwin.com/problems.html ! that is what i was talking about, a simple and clean tutorial that shows what needs to be done for setting a working cygwin + gnome2 environment without having to read hundreds of hard-to-find FAQ/Docs... i can't say I have much spare time to do that. That's also one of the puroposes of this ng, I think. Thanks for the healp anyway, Alessandro -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nfs-server-config died (Attn: nfs-server maintainer)
On Thu, 12 Jan 2006, Hiroki Sakagami wrote: When I executed /usr/bin/nfs-server-config, it died around line 223 due to the assignment to readonly variable $UID. Is this a known issue? The version of the package is nfs-server-2.3-3. This probably has to do with the switch of /bin/sh from ash to bash. UID is a reserved variable in bash, but not in ash. The variable needs to be renamed. Sam? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CLISP 2.37 is really 2.36?
* Toby Allsopp [EMAIL PROTECTED] [2006-01-12 10:13:06 +1300]: $ cygcheck -c clisp Cygwin Package Information Package VersionStatus clisp2.37-1 OK $ which clisp /usr/bin/clisp $ clisp --version GNU CLISP 2.36 (2005-12-04) (built on winsteingoldlap.bluelnk.net [192.168.7.100]) oops - packaging bug. don't worry, this _is_ 2.37 -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.jihadwatch.org http://www.palestinefacts.org http://pmw.org.il http://truepeace.org http://ffii.org http://www.dhimmi.com There is an exception to every rule, including this one. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated Cygwin Package: fetchmail-6.3.1-1
On Wed, 4 Jan 2006, Jason Tishler wrote: New News: === I have updated the version of fetchmail to 6.3.1-1. The tarballs should be available on a Cygwin mirror near you shortly. The only change between this version and the previous one is the following: o update to version 6.3.1 I've updated fetchmail today and I no longer get visual feedback about its progress when messages are being retrieved. Instead printing on the terminal the information is recorder in the Event log. Is this expected ? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash 3.1-1 exec -l doesn't start login shell
On 1/11/2006 9:06 PM, Eric Blake wrote: exec -l in bash 3.1-1 doesn't seem to start a login shell. This prevents my chere commands from starting a login shell, too. I couldn't reproduce the failure; can you provide more details? Here's what I tried: [snip program] So exec -l is correctly prepending the '-' to argv[0]. Is you question about bash not behaving as a login shell when invoked with argv[0] set to -bash? I guess so. Have you tried bash --login instead? bash --login works fine, but the problem with -bash prevents chere from starting login shells. It may be possible to modify chere to use bash --login, but this is still a bash bug, right? As I said, I noticed the problem first with chere. I confirmed the problem by adding echo `date` ~/.profile /tmp/dotfile at the top of ~/.profile. When I start a shell with bash --login, I see the current date/time added to /tmp/dotfile. If I execute exec -l /bin/bash, no entry is added to /tmp/dotfile with 3.1-1. An entry is added with 3.0-14. -- David Rothenbergerspammer? - [EMAIL PROTECTED] GPG/PGP: 0x92D68FD8, DB7C 5146 1AB0 483A 9D27 DFBA FBB9 E328 92D6 8FD8 Your program is sick! Shoot it and put it out of its memory. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with running Gnome applications
On Thu, Jan 12, 2006 at 03:23:42PM +0100, Alessandro Lendaro wrote: Dave Korn wrote: This is a http://cygwin.com/acronyms#WAG, but have you got CYGWIN=server set in your environment, and are you running the cygserver? That's a pretty common cause of Bad system call errors. Of course, I would already have known the answer to those two questions if you had sent your cygcheck output as an attachment, like it says at http://cygwin.com/problems.html ! that is what i was talking about, a simple and clean tutorial that shows what needs to be done for setting a working cygwin + gnome2 environment without having to read hundreds of hard-to-find FAQ/Docs... i can't say I have much spare time to do that. I wouldn't think that there would be any reason to tell us about your spare time constraints if time is in short supply. It's probably better to just cut your losses. That's also one of the puroposes of this ng, I think. Answering questions about the cygwin distribution is one of the reasons for this mailing list but it is not unreasonable to expect that the person asking questions will be willing to spend some time reading the easy-to-find documentation at the web site so that, when they ask a question, they do so in a manner that is more likely to provide them with effective help. That said, however, we don't provide support for cygwinports. You downloaded that from another site and there is another mailing list devoted to it. The fact that it has the word cygwin in it doesn't mean that many people here are familiar with it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [ANNOUNCEMENT] Updated: fftw3-3.0.1-2
On Thu, Jan 12, 2006 at 05:53:31AM -0800, James R. Phillips wrote: Chris, My records show I only sent this out once, to the announcements list, and it did not have any [ANNOUNCEMENT] header tacked on to the front of the subject. I am mystified as to how it showed up again, with double header, both on the cygwin and on the announcement list. I would like to say I'll avoid such an error in the future; however in this case it does not appear to me that I made any such error. Hmm. Ok. Sorry. So there are two problems here (one software, one wetware) and both of them are mine. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: once more into the breach - please try a snapshot so I can release this thing
On Jan 12 06:03, Eric Blake wrote: cygserver.exe - Entry Point Not Found The procedure entry point IsWow64Process could not be located in the dynamic link library KERNEL32.dll Thanks, that should be fixed now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Define _POSIX_SOURCE in cygwin's features.h?
Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? cgf P.S. I know that Cygwin isn't fully compliant with POSIX specifications. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with running Gnome applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alessandro Lendaro wrote: It would be cool to have a clean and as complete as possible tutorial/wiki with infos about installing Gnome and applicationso n cygwin and make them work. Installing GNOME programs on Cygwin is no different than other packages, and running them should be no different then on *NIX (except that the full desktop doesn't work yet). I got many problems with gconfd (errors like this: 1) gconfd-2 should not be started manually; programs that need it will spawn it automatically. 2) AFAIK on Cygwin, gconfd-2 isn't very good about deleting its lock file; try the following before starting your GNOME app again: $ gconftool-2 --shutdown $ ps -a [make sure gconfd-2 isn't running, else /bin/kill it] $ rm -fr $TMP/gconfd-* i cant execute bluefish ( Bad system call message) You need to update gtk2-x11-runtime from the distro to 2.6.10-1. (There's another solution, but this is the simplest.) I have Win 2003 server and latest Cygwin/Cygwin ports installation. I haven't tried GNOME (or Cygwin FTM) on Win2003, so I have no idea how it works there. Please note that I've set the Reply-To: header on this message. Further questions about Cygwin Ports packages need to be directed to the cygwin-ports-general list, not here. Yaakov Cygwin Ports -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxpMzpiWmPGlmQSMRAqe5AKDfVBBz0iRdsKXfAnMjqnnjh8mK3gCgyydm gaFdNWa2RekpJX/HvKsxQB8= =azj4 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? cgf P.S. I know that Cygwin isn't fully compliant with POSIX specifications. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. IOW, the system headers should have nothing to say about it at all, although they may well want to react to it if it is defined at the time they are #included. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 05:40:35PM -, Dave Korn wrote: Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. Any opinions on this? Eric? P.S. I know that Cygwin isn't fully compliant with POSIX specifications. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. No need to use google. Just grep for it in /usr/include on linux. _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE # undef _ISOC99_SOURCE # define _ISOC99_SOURCE 1 # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE199506L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 600 # undef _XOPEN_SOURCE_EXTENDED # define _XOPEN_SOURCE_EXTENDED 1 # undef _LARGEFILE64_SOURCE # define _LARGEFILE64_SOURCE1 # undef _BSD_SOURCE # define _BSD_SOURCE1 # undef _SVID_SOURCE # define _SVID_SOURCE 1 #endif So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem with cron
Mike Stathopoulos schrieb: I having problems running the cron on my system. Can you help? USER = `mike.stathopoulos' cygrunsrv --start cron cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062: The service has not been started. Maybe the user is not Administrator and not in the Administrators Group, and therefore has not the necessary privileges to start a service. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Hi, Christopher Faylor, le Thu 12 Jan 2006 12:59:08 -0500, a écrit : Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. If the package doesn't define _POSIX_SOURCE itself then it needs be fixed, not cygwin. _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. Indeed. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... # define _POSIX_SOURCE 1 ... #endif So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. No. It can create a lot of other problems. Maybe cygwin could #define _POSIX_SOURCE to 1 if the user _already_ defined _GNU_SOURCE. But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. Regards, Samuel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. I think it would be the opposite. 1) In glibc, _POSIX_SOURCE is defined by features.h based on a number of conditions[1]. The newlib/Cygwin features.h isn't nearly so thorough. [1] http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/features.h?cvsroot=glibc 2) After running a grep of /usr/include, it looks like arbitrarily defining _POSIX_SOURCE in Cygwin would cause a significant number of constants and functions to never be defined (and AFAICS there would be no simple way to undef it within code), without actually adding anything, for example: /usr/include/dirent.h:#if !defined(MAXNAMLEN) !defined(_POSIX_SOURCE) /usr/include/fnmatch.h:#ifndef _POSIX_SOURCE /usr/include/glob.h:#ifndef _POSIX_SOURCE /usr/include/grp.h:#if !defined(_POSIX_SOURCE) !defined(_XOPEN_SOURCE) /usr/include/grp.h:#ifndef _POSIX_SOURCE /usr/include/pwd.h:#ifndef _POSIX_SOURCE /usr/include/pwd.h:#ifndef _POSIX_SOURCE /usr/include/sys/dirent.h:#ifndef _POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/fcntl.h:#ifndef_POSIX_SOURCE /usr/include/sys/select.h:#if !defined (_POSIX_SOURCE) !defined (__INSIDE_CYGWIN_NET__) /usr/include/sys/stat.h:#ifndef _POSIX_SOURCE /usr/include/sys/types.h:# ifndef _POSIX_SOURCE /usr/include/sys/types.h:# if !(defined (_POSIX_SOURCE) || defined (_WINSOCK_H) || defined (__USE_W32_SOCKETS)) /usr/include/sys/unistd.h:#ifndef_POSIX_SOURCE 3) I think that, in many cases, _POSIX_SOURCE is defined in code if desired (and that would have been the best solution in the aforementioned case). 4) I'm sure I remember a few times that, even when _POSIX_SOURCE was defined in code, I had to #ifndef __CYGWIN__ that define due to compile errors; I can't remember having to manually add such a define, however. My $0.02, YMMV. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxpt3piWmPGlmQSMRAp2sAJ0TxKcHtdl7UCIk1+V3hvF121CRiQCgwnF5 JwyP3gsv3xzBvADntvAgyfo= =CWnC -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: On Thu, Jan 12, 2006 at 05:40:35PM -, Dave Korn wrote: Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. As far as I can tell by googling, _POSIX_SOURCE, despite the leading underscore, is in fact a user-land feature test macro that it is up to each individual application to decide whether to switch it on or not according to whether the application itself is compliant or not. No need to use google. Just grep for it in /usr/include on linux. Um, I know all about the -A/-B/-C switches that get grep to show you the context around the search match, but I don't know what option switch you pass to grep to get it to show you the semantic meaning of the matched text _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... which is equally something that belongs to and is under control of the user's application, and is a way for the user's application to specify (to the compiler, C runtime, and whoever else) that it's compliant and requires/copes with POSIX compliant source in the system header files. So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. I think it means that whoever you were talking to in the IRC channel should have defined _POSIX_SOURCE in their application, and the bug is that they didn't when they should have. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 12:09:59PM -0600, Yaakov S (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: Someone on the cygwin irc channel had a problem building a package which would have been solved if Cygwin defined _POSIX_SOURCE. I know that Cygwin is not fully POSIX compliant (I really really do) but I'm wondering if setting _POSIX_SOURCE in the cygwin headers wouldn't solve more porting problems than it creates. I think it would be the opposite. 1) In glibc, _POSIX_SOURCE is defined by features.h based on a number of conditions[1]. The newlib/Cygwin features.h isn't nearly so thorough. I am going to regret not making that clear, aren't I? 2) After running a grep of /usr/include, it looks like arbitrarily defining _POSIX_SOURCE in Cygwin would cause a significant number of constants and functions to never be defined (and AFAICS there would be no simple way to undef it within code), without actually adding anything, for example: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. 3) I think that, in many cases, _POSIX_SOURCE is defined in code if desired (and that would have been the best solution in the aforementioned case). So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. 4) I'm sure I remember a few times that, even when _POSIX_SOURCE was defined in code, I had to #ifndef __CYGWIN__ that define due to compile errors; I can't remember having to manually add such a define, however. I was hoping for concrete examples. Do you have any? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor, le Thu 12 Jan 2006 13:13:39 -0500, a écrit : On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. Then don't ask for your programs to get compiled under other systems than GNU. Defining _GNU_SOURCE without defining _POSIX_SOURCE just means you only target GNU systems. Cygwin is not a GNU system. I'm interested in hearing if this will fix problems with programs which build without problem on linux. Maybe, but it's a really _wrong_ approach which cannot but just degrade cygwin's POSIX compliancy. Regards, Samuel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. cgf But it seems that it only builds without problem on Linux by chance, not by design. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. Now, we could put masses of code into cygwin to try and reproduce whatever feature it is of the Linux memory layout that allows these programs to get away with overrunning their buffers and not crash, but I think that would be a deeply silly and overly-complicated attempt to 'help' users with potentially lots of side-effects that would cause problems for everyone, not just writers of buggy programs, and I think that this is an (admittedly less extreme) example of the same thing. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:20:21PM +0100, Samuel Thibault wrote: Christopher Faylor, le Thu 12 Jan 2006 13:13:39 -0500, a ?crit : On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. Then don't ask for your programs to get compiled under other systems than GNU. Ok. I won't. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 06:13:16PM -, Dave Korn wrote: Christopher Faylor wrote: _POSIX_SOURCE is defined in features.h on linux under control of the _GNU_SOURCE macro. /* If _GNU_SOURCE was defined by the user, turn on all the other features. */ #ifdef _GNU_SOURCE ... which is equally something that belongs to and is under control of the user's application, and is a way for the user's application to specify (to the compiler, C runtime, and whoever else) that it's compliant and requires/copes with POSIX compliant source in the system header files. ...which doesn't really invalidate the question of whether cygwin should be trying to set up its headers the same way as linux. So, let me clarify. Should we define _POSIX_SOURCE similarly to the way that linux does it? This may mean that we have to define _GNU_SOURCE also and maybe that's not a good idea but, again, it might solve more problems than it causes. I think it means that whoever you were talking to in the IRC channel should have defined _POSIX_SOURCE in their application, and the bug is that they didn't when they should have. Ok. I assumed that some header set _GNU_SOURCE but apparently I was wrong. I should have checked. Just to add even more clarification, this wasn't some guy writing a program for his class assignment. It was someone trying to port a standard linux/unix application. The program had a test for _POSIX_SOURCE which would have worked correctly under Cygwin. I don't know if it was setting _GNU_SOURCE to get this or if the _POSIX_SOURCE test just wasn't discovered by configure. So, maybe this boils down to the question of whether there's something about Cygwin which makes configure think it shouldn't set _POSIX_SOURCE or _GNU_SOURCE. Maybe it is just that uname doesn't return the string linux. Again, I'm not really interested in hearing what someone should have done or should have known to do. If there is a way to make porting a program to cygwin easier without requiring some special knowledge that isn't required on linux, then I'll probably take steps to make that happen. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 06:22:11PM -, Dave Korn wrote: Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. But it seems that it only builds without problem on Linux by chance, not by design. That is by no means clear but even if that was the case, I don't care. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 01:53:50PM -0500, Christopher Faylor wrote: On Thu, Jan 12, 2006 at 06:22:11PM -, Dave Korn wrote: Christopher Faylor wrote: On Thu, Jan 12, 2006 at 07:08:32PM +0100, Samuel Thibault wrote: But a portable program should _not_ assume that #defining _GNU_SOURCE implies that _POSIX_SOURCE. If a program not only needs posix stuff but also some GNU extras, it should #define _GNU_SOURCE _and_ _POSIX_SOURCE itself. I don't care about portable programs. I'm interested in hearing if this will fix problems with programs which build without problem on linux. But it seems that it only builds without problem on Linux by chance, not by design. That is by no means clear but even if that was the case, I don't care. I don't see why we should try and fix this in cygwin. Consider how many times people come here and say My app works fine on Linux, how come it just dies with a SEGV on cygwin and someone points out the trivially obvious buffer overrun and we have to explain how it only ever worked on Linux by luck because of differences in the environment and the way the stack is set up. If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. Editing glitch above. Please change '?' to '.'. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Define _POSIX_SOURCE in cygwin's features.h?
Christopher Faylor wrote: If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. I understand yours too, and it's equally valid. I'm curious why someone's application would want to test _POSIX_SOURCE - it should be the app that sets it or not and it should just know. But if they've handed the responsibility to auto* to determine when to use it, and auto* decides YES for Linux, then I agree it should certainly DTST on Cygwin. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 07:06:43PM -, Dave Korn wrote: Christopher Faylor wrote: If I could easily make cygwin behave exactly the same way so that a buffer overrun that worked on linux went undetected on cygwin, too, I'd do that? If there was some linker option to ensure that, I'd use it. The point of cygwin isn't that it is a place where you find bugs which you should have fixed on linux. Every place where there is a barrier to porting a program from linux to cygwin is YA opportunity for someone to give up in disgust or (maybe worse) send a I get compile error message here. But, I understand your opinion on the matter. I understand yours too, and it's equally valid. I'm curious why someone's application would want to test _POSIX_SOURCE - it should be the app that sets it or not and it should just know. But if they've handed the responsibility to auto* to determine when to use it, and auto* decides YES for Linux, then I agree it should certainly DTST on Cygwin. This particular application was ircd. It was testing _POSIX_SOURCE (and a few other defines) to determine whether it should use setsid or a two-argument version of setpgrp, e.g.: #ifdef _POSIX_SOURCE setsid (); #else setpgr(..., ...); #endif Again, I should have tested what I was talking about. It turns out that _POSIX_SOURCE *is* turned on by default on in glibc regardless of whether you define _GNU_SOURCE or not. So that would explain why this application built. Apparently _POSIX_SOURCE is turned on by this segment of features.h: #if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) = 500) \ !defined _POSIX_SOURCE !defined _POSIX_C_SOURCE) # define _POSIX_SOURCE 1 # if defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 500 # define _POSIX_C_SOURCE 2 # else # define _POSIX_C_SOURCE 199506L # endif #endif The application in question *could* have done things differently but there is no way that this irc user would have been capable of making any changes to accomplish this. I was wondering if anyone had specific examples where defining _POSIX_SOURCE would help or hurt existing applications. I understand that it wouldn't be as simple as just defining _POSIX_SOURCE in a header and then walking away but I'm willing to look into fixing up the cygwin header files to do the right thing (for all I know, they already do) when _POSIX_SOURCE is defined. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl/TK Missing Dependency Found
Yaakov, if you would be willing to post the debugging symbols for Tk.dll, I could try ferreting out some more info. Unfortunately, I'm not up to building a debug version of Perl/Tk at the moment. I don't recall off-hand who maintains libfontconfig (Harold?), but it's unlikely to be a fontconfig problem anyway. Have the debugging symbols been posted or the maintainer of libfontconfig looked into this? Brett Brett C. Serkez, Techie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: nfs-server-config died (Attn: nfs-server maintainer)
On Thu, 12 Jan 2006, Hiroki Sakagami wrote: When I executed /usr/bin/nfs-server-config, it died around line 223 due to the assignment to readonly variable $UID. Is this a known issue? The version of the package is nfs-server-2.3-3. This probably has to do with the switch of /bin/sh from ash to bash. UID is a reserved variable in bash, but not in ash. The variable needs to be renamed. Sam? You learn something new every day. Thanks for explaining this, Igor :-) Actually, the variable can be eliminated - it was left over from a previous version of the script, and isn't actually referenced. For now, you should be able to comment out (or delete) the line that makes the assignment to the UID variable. I'll see about getting a new version of nfs-server out with this fix later today. -Samrobb -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Faylor wrote: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. Right now, all _POSIX_SOURCE seems to do is exclude a number of constants and functions from being defined, supposedly because they aren't part of the POSIX standard. Now, newlib != glibc, but the examples I mentioned before could be compared to their glib counterparts (see below regarding sys/select.h). So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. OK, but I think these are uncommon cases; I've built a *LOT* of packages of all types, and this has not generally been a problem. I was hoping for concrete examples. Do you have any? gmime2: gmime-gpg-context.c: In function `gpg_ctx_op_step': gmime-gpg-context.c:1089: error: `fd_set' undeclared (first use in this function) gmime-gpg-context.c:1089: error: (Each undeclared identifier is reported only once gmime-gpg-context.c:1089: error: for each function it appears in.) gmime-gpg-context.c:1089: error: parse error before rdset gmime-gpg-context.c:1096: error: `rdset' undeclared (first use in this function) gmime-gpg-context.c:1114: error: `wrset' undeclared (first use in this function) gmime-gpg-context.c:1124: error: `wrsetp' undeclared (first use in this function) fd_set is defined in sys/types.h (which is also called by sys/select.h, but only if !defined(_POSIX_SOURCE)), but with this condition: /* We don't define fd_set and friends if we are compiling POSIX source, or if we have included (or may include as indicated by __USE_W32_SOCKETS) the W32api winsock[2].h header which defines Windows versions of them. Note that a program which includes the W32api winsock[2].h header must know what it is doing; it must not call the cygwin32 select function. */ # if !(defined (_POSIX_SOURCE) || defined (_WINSOCK_H) || defined (__USE_W32_SOCKETS)) AFAICS, in glibc, fd_set is (independent of _POSIX_SOURCE) defined via sys/select.h. Since _POSIX_SOURCE on Cygwin doesn't add anything, I can't remember a case that I've had to *add* such a define. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxrujpiWmPGlmQSMRAiZtAKCW/vRO4Ihfop9vJLdKYs0mPvNCgwCfUHh/ 3ziKVCCYkJnGCTnMtgkirec= =bUjT -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
On Thu, Jan 12, 2006 at 02:27:17PM -0600, Yaakov S (Cygwin Ports) wrote: Christopher Faylor wrote: I guess more subtext that you could read into my request would be that we would make the headers work as closely as possible to linux when _POSIX_SOURCE is defined. The key here is to make things look more like linux so that programs port more easily. Right now, all _POSIX_SOURCE seems to do is exclude a number of constants and functions from being defined, supposedly because they aren't part of the POSIX standard. Now, newlib != glibc, but the examples I mentioned before could be compared to their glib counterparts (see below regarding sys/select.h). Wouldn't that follow from my we would make the headers work as closely as possible to linux? So, that would imply that we really should actively fix up the headers to make sure that it is properly handled. OK, but I think these are uncommon cases; I've built a *LOT* of packages of all types, and this has not generally been a problem. I would not expect that there would ever be a case where defining _POSIX_SOURCE would help you on cygwin since you have discovered that it is not correctly handled in cygwin headers. I was hoping for concrete examples. Do you have any? gmime2: gmime-gpg-context.c: In function `gpg_ctx_op_step': gmime-gpg-context.c:1089: error: `fd_set' undeclared (first use in this function) gmime-gpg-context.c:1089: error: (Each undeclared identifier is reported only once gmime-gpg-context.c:1089: error: for each function it appears in.) gmime-gpg-context.c:1089: error: parse error before rdset gmime-gpg-context.c:1096: error: `rdset' undeclared (first use in this function) gmime-gpg-context.c:1114: error: `wrset' undeclared (first use in this function) gmime-gpg-context.c:1124: error: `wrsetp' undeclared (first use in this function) fd_set is defined in sys/types.h (which is also called by sys/select.h, but only if !defined(_POSIX_SOURCE)), but with this condition: Of course if cygwin uses _POSIX_SOURCE incorrectly it will cause problems. I'm talking about fixing that. Since _POSIX_SOURCE on Cygwin doesn't add anything, I can't remember a case that I've had to *add* such a define. I'm talking about cases where source code to be ported would have ported more easily because it relied on _POSIX_SOURCE turning on some functionality that was available in cygwin (the cygwin header file problems notwithstanding). cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: nfs-server-2.3-4
I've updated the nfs-server package for Cygwin to version 2.3-4. This release corrects a problem with trying to assign to a reserved shell variable in the nfs-server-config script. *** INSTALLATION *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. - Sam Robb ([EMAIL PROTECTED]) - http://www.timesys.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl/TK Missing Dependency Found (Attn: libfontconfig maintainer)
On Thu, 12 Jan 2006, Brett Serkez wrote: Yaakov, if you would be willing to post the debugging symbols for Tk.dll, I could try ferreting out some more info. Unfortunately, I'm not up to building a debug version of Perl/Tk at the moment. I don't recall off-hand who maintains libfontconfig (Harold?), but it's unlikely to be a fontconfig problem anyway. Have the debugging symbols been posted or the maintainer of libfontconfig looked into this? I haven't seen any messages to that regard. It was a bit unfortunate that the subject wasn't changed, and the libfontconfig maintainer can't be expected to read every message on the Cygwin list. Hopefully the new subject will flag his attention. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl/TK Missing Dependency Found (Attn: libfontconfig maintainer)
Yaakov, if you would be willing to post the debugging symbols for Tk.dll, I could try ferreting out some more info. Unfortunately, I'm not up to building a debug version of Perl/Tk at the moment. I don't recall off-hand who maintains libfontconfig (Harold?), but it's unlikely to be a fontconfig problem anyway. Have the debugging symbols been posted or the maintainer of libfontconfig looked into this? I haven't seen any messages to that regard. It was a bit unfortunate that the subject wasn't changed, and the libfontconfig maintainer can't be expected to read every message on the Cygwin list. Hopefully the new subject will flag his attention. Yes, this is a busy list. But.. as a practical matter, installation of libmwf resolves the issue, so while I can understand wanting to dig thru this, I'm not sure why this dependency isn't simply included as I originally suggested. Oh well, I found the issue for myself, I suppose the next poor soul will re-live the pain. Brett Brett C. Serkez, Techie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl/TK Missing Dependency Found (Attn: libfontconfig maintainer)
On Thu, Jan 12, 2006 at 04:20:27PM -0500, Brett Serkez wrote: Oh well, I found the issue for myself, I suppose the next poor soul will re-live the pain. Or the one after that if we just band-aid the problem without actually understanding it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
inetutils-1.3.2-34: setsockopt warning from ftp
=4.0 img=1.0 sys=4.0 cygxerces-c23.dll v0.0 ts=2003/10/11 19:36 3416k 2004/02/21 c:\cygwin\bin\cygxerces-c25.dll - os=4.0 img=1.0 sys=4.0 cygxerces-c25.dll v0.0 ts=2004/2/20 22:49 1430k 2005/11/18 c:\cygwin\bin\cygxml2-2.dll - os=4.0 img=1.0 sys=4.0 cygxml2-2.dll v0.0 ts=2005/11/18 9:48 50k 2003/08/09 c:\cygwin\bin\cygXpm-noX4.dll - os=4.0 img=1.0 sys=4.0 cygXpm-noX4.dll v0.0 ts=2003/8/9 0:21 54k 2003/08/09 c:\cygwin\bin\cygXpm-X4.dll - os=4.0 img=1.0 sys=4.0 cygXpm-X4.dll v0.0 ts=2003/8/9 0:22 200k 2005/12/10 c:\cygwin\bin\cygxslt-1.dll - os=4.0 img=1.0 sys=4.0 cygxslt-1.dll v0.0 ts=2005/12/9 16:43 65k 2005/08/23 c:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0 cygz.dll v0.0 ts=2005/8/22 19:03 1764k 2006/01/12 c:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2006/1/12 10:01 Cygwin DLL version info: DLL version: 1.5.19 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 150 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Thu Jan 12 10:01:11 PST 2006 Snapshot date: 20060112-09:27:37 Shared id: cygwin1S4 243k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygdps-1.dll - os=4.0 img=1.0 sys=4.0 cygdps-1.dll v0.0 ts=2005/2/23 6:42 26k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygdpstk-1.dll - os=4.0 img=1.0 sys=4.0 cygdpstk-1.dll v0.0 ts=2005/2/23 6:42 28k 2004/03/31 C:\cygwin\usr\X11R6\bin\cygDtPrint-1.dll - os=4.0 img=1.0 sys=4.0 cygDtPrint-1.dll v0.0 ts=2004/3/30 20:23 167k 2003/10/17 C:\cygwin\usr\X11R6\bin\cygfontconfig-1.dll - os=4.0 img=1.0 sys=4.0 cygfontconfig-1.dll v0.0 ts=2003/10/16 21:11 21k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygfontenc-1.dll - os=4.0 img=1.0 sys=4.0 cygfontenc-1.dll v0.0 ts=2005/2/23 6:45 282k 2003/10/28 C:\cygwin\usr\X11R6\bin\cygfreetype-9.dll - os=4.0 img=1.0 sys=4.0 cygfreetype-9.dll v0.0 ts=2003/10/17 23:44 36k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygFS-6.dll - os=4.0 img=1.0 sys=4.0 cygFS-6.dll v0.0 ts=2005/2/23 6:34 358k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygGL-1.dll - os=4.0 img=1.0 sys=4.0 cygGL-1.dll v0.0 ts=2005/2/23 6:39 438k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygGLU-1.dll - os=4.0 img=1.0 sys=4.0 cygGLU-1.dll v0.0 ts=2005/2/23 6:41 140k 2004/08/06 C:\cygwin\usr\X11R6\bin\cygglut-3.dll - os=4.0 img=1.0 sys=4.0 cygglut-3.dll v0.0 ts=2004/8/6 7:43 75k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygICE-6.dll - os=4.0 img=1.0 sys=4.0 cygICE-6.dll v0.0 ts=2005/2/23 6:28 77k 2004/03/31 C:\cygwin\usr\X11R6\bin\cygMrm-2.dll - os=4.0 img=1.0 sys=4.0 cygMrm-2.dll v0.0 ts=2004/3/30 20:23 9k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygoldX-6.dll - os=4.0 img=1.0 sys=4.0 cygoldX-6.dll v0.0 ts=2005/2/23 6:28 1413k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygOSMesa-4.dll - os=4.0 img=1.0 sys=4.0 cygOSMesa-4.dll v0.0 ts=2005/2/23 6:39 41k 2002/05/14 C:\cygwin\usr\X11R6\bin\cygPropList-0.dll - os=4.0 img=1.0 sys=4.0 cygPropList-0.dll v0.0 ts=2002/5/13 20:13 20k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygpsres-1.dll - os=4.0 img=1.0 sys=4.0 cygpsres-1.dll v0.0 ts=2005/2/23 6:42 30k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygSM-6.dll - os=4.0 img=1.0 sys=4.0 cygSM-6.dll v0.0 ts=2005/2/23 6:28 66k 2004/03/31 C:\cygwin\usr\X11R6\bin\cygUil-2.dll - os=4.0 img=1.0 sys=4.0 cygUil-2.dll v0.0 ts=2004/3/30 20:23 877k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygX11-6.dll - os=4.0 img=1.0 sys=4.0 cygX11-6.dll v0.0 ts=2005/2/23 6:28 254k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygXaw-6.dll - os=4.0 img=1.0 sys=4.0 cygXaw-6.dll v0.0 ts=2005/2/23 6:31 356k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygXaw-7.dll - os=4.0 img=1.0 sys=4.0 cygXaw-7.dll v0.0 ts=2005/2/23 6:32 363k 2005/02/23 C:\cygwin\usr\X11R6\bin\cygXaw-8.dll - os=4.0 img=1.0 sys=4.0 cygXaw-8.dll v0.0 ts=2005/2/23 6:33 701k 2003/09/23 C:\cygwin\usr\X11R6\bin\cygXaw3d-1.dll - os=4.0 img=1.0 sys=4.0 cygXaw3d-1.dll v0.0 ts=2003/9/23 0:34 275k 2004/01/13 C:\cygwin\usr\X11R6\bin\cygXaw3d-7.dll - os=4.0 img=1.0 sys=4.0 cygXaw3d-7.dll v0.0 ts=2004/1/13 14:17 9k 2005/02/23 C:\cygwin
Re: Perl/TK Missing Dependency Found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Peshansky wrote: I can reproduce this on WinXP Pro SP1 (cygcheck output attached). Adding Perl/Tk to my installation and running the program in Brett's message (http://cygwin.com/ml/cygwin/2006-01/msg00423.html) causes a SIGSEGV. I don't have a debugging version of Perl, Perl/Tk, or fontconfig, but, FWIW, here's the backtrace I get from gdb (some inconsequental output snipped): fontconfig??? Looks like I had the wrong perl-Tk release uploaded, the one with 'experimental' Xft support, and not the standard one on my system (which is why I couldn't dup this). Now we all know why it's experimental. Look for a release -4 soon which should fix this. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxtFYpiWmPGlmQSMRArhHAKCo2+sOsNy5rbDSs8r/vVBj+lo/VACg1YSI xnOwtQ4C+dDDYoZ4z6p+r1w= =zVQ5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl/TK Missing Dependency Found
I can reproduce this on WinXP Pro SP1 (cygcheck output attached). Adding Perl/Tk to my installation and running the program in Brett's message (http://cygwin.com/ml/cygwin/2006-01/msg00423.html) causes a SIGSEGV. I don't have a debugging version of Perl, Perl/Tk, or fontconfig, but, FWIW, here's the backtrace I get from gdb (some inconsequental output snipped): fontconfig??? Looks like I had the wrong perl-Tk release uploaded, the one with 'experimental' Xft support, and not the standard one on my system (which is why I couldn't dup this). Now we all know why it's experimental. Look for a release -4 soon which should fix this. Oh boy, what a run around for such a simple resolution. I am very grateful having a 'native' Perl/TK for Cygwin vs. having to using ActivePerl and shell out to Cygwin scripts, but this could have been an easier transition. Yes, I will look for the release with much anticipation and test as soon as it does. Thank you, Brett Brett C. Serkez, Techie -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
problems with unistd.h
Hi There,
I get the following error while compiling flite. Is
this a Cygwin problem? Any help will be greatly
appreciated.
Thank you.
SBO
Configuration: flite - Win32
Debug
Compiling...
au_none.c
c:\cygwin\usr\include\mingw\unistd.h(23) : error
C2081: 'off_t' : name in formal parameter list illegal
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2054: expected '(' to follow '__CRT_INLINE'
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2146: syntax error : missing ')' before identifier
'__length'
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2081: 'off_t' : name in formal parameter list illegal
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2082: redefinition of formal parameter 'ftruncate'
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2146: syntax error : missing ',' before identifier
'__length'
c:\cygwin\usr\include\mingw\unistd.h(24) : error
C2059: syntax error : ')'
c:\cygwin\usr\include\mingw\unistd.h(25) : error
C2143: syntax error : missing ';' before '{'
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?
On 1/11/06, Igor Peshansky wrote: Hi, I believe I'm up-to-date with xmlto and DocBook on Cygwin. Still, I was unable to build either the user's guide or the FAQ from sources. Part of the problem was a bug in doctool.c (for which I'll send a patch to cygwin-patches shortly). However, even with that bug fixed, I got the following error: I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd /usr/src/cygwin-cvs/build/i686-pc-cygwin/winsup/doc/cygwin-ug-net.sgml:3: warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;[] ^ (with a bunch of other errors about undefined entities, which, I believe, followed from the above). I traced this down to the /usr/bin/xmlto, which invokes xsltproc with the --nonet option. A question to the xmlto maintainer: is there a particular reason this option is being used? Obviously somebody was able to successfully build the FAQ and User's guide. Was this using Cygwin? If so, what versions of xmlto and the various DocBook packages were used? I build everything but the PDFs on Cygwin. Is your issue related to http://www.cygwin.com/ml/cygwin-apps/2005-10/msg00065.html I.e., you have docbook-xml42 installed? It might help to send info as at http://www.cygwin.com/problems.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Define _POSIX_SOURCE in cygwin's features.h?
Hi,
Christopher Faylor, le Thu 12 Jan 2006 13:47:10 -0500, a écrit :
Just to add even more clarification, this wasn't some guy writing a
program for his class assignment. It was someone trying to port a
standard linux/unix application.
If he doesn't define _POSIX_SOURCE for getting function definitions, his
application isn't a standard unix one.
The program had a test for _POSIX_SOURCE which would have worked
correctly under Cygwin. Again, I'm not really interested in hearing
what someone should have done or should have known to do.
Christopher Faylor, le Thu 12 Jan 2006 14:24:23 -0500, a écrit :
This particular application was ircd. It was testing _POSIX_SOURCE (and
a few other defines) to determine whether it should use setsid or a
two-argument version of setpgrp, e.g.:
#ifdef _POSIX_SOURCE
setsid ();
#else
setpgrp(..., ...);
#endif
Testing for _POSIX_SOURCE _doesn't_ make sense. Read a posix book. One
of the first things it would tell you is that you must define
_POSIX_SOURCE yourself for pulling posix function definitions such.
If a programmer wants to determine whether setsid or setpgr can be used,
he can just use an autoconf rule for that. I repeat: read posix, testing
for _POSIX_SOURCE does _not_ make sense in a program.
Christopher Faylor, le Thu 12 Jan 2006 13:53:50 -0500, a écrit :
I don't see why we should try and fix this in cygwin.
Consider how many times people come here and say My app works fine on
Linux, how come it just dies with a SEGV on cygwin and someone points
out the trivially obvious buffer overrun and we have to explain how it
only ever worked on Linux by luck because of differences in the
environment and the way the stack is set up.
If I could easily make cygwin behave exactly the same way so that a
buffer overrun that worked on linux went undetected on cygwin, too, I'd
do that. If there was some linker option to ensure that, I'd use it.
This is /weird/. Reproducing bugs is just silly ! 8!
It turns out that _POSIX_SOURCE *is* turned on by default on in glibc
regardless of whether you define _GNU_SOURCE or not. So that would
explain why this application built.
Apparently _POSIX_SOURCE is turned on by this segment of features.h:
#if ((!defined __STRICT_ANSI__ || (_XOPEN_SOURCE - 0) = 500) \
!defined _POSIX_SOURCE !defined _POSIX_C_SOURCE)
# define _POSIX_SOURCE 1
# if defined _XOPEN_SOURCE (_XOPEN_SOURCE - 0) 500
# define _POSIX_C_SOURCE 2
# else
# define _POSIX_C_SOURCE 199506L
# endif
#endif
Ok, now _this_ makes sense. This is a lazyness of GNU people: gcc
is _not_ an ansi compiler, only gcc -ansi is ; and in that case
__STRICT_ANSI__ is defined for headers to avoid defining things like
_POSIX_C_SOURCE themselves.
Since cygwin uses the gcc compiler, these few lines should _indeed_ be
added to features.h. But not more !
(BTW, that means that ircd can only be compiled with a gcc compiler, not
an ansi compiler).
I was wondering if anyone had specific examples where defining
_POSIX_SOURCE would help or hurt existing applications.
It can hurt:
#include unistd.h
#include stdio.h
#include stdlib.h
static const char *confstr(num)
unsigned int num;
{
static const char *strs[] = { foo, bar, baz };
if (num = sizeof(strs)/sizeof(*strs))
return unknown;
return strs[num];
}
int main(argc, argv)
int argc;
char *argv[];
{
char *conf;
argv++;
while ((conf = *(argv++)))
puts(confstr(atoi(conf)));
return 0;
}
This program is a perfectly valid ansi C program:
$ gcc test.c -o test -ansi -Wall -pedantic
It compiles fine with ansi C compilers.
But it is not a valid posix C program:
$ gcc test.c -o test
test.c:5: error: conflicting types for 'confstr'
/usr/include/unistd.h:544: error: previous declaration of 'confstr' was here
So, does cygwin want gcc to be by default an ansi compiler or a posix
compiler?
Regards,
Samuel
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: problems with unistd.h
Burcu Ozserim wrote: c:\cygwin\usr\include\mingw\unistd.h(23) : error C2081: 'off_t' : name in formal parameter list illegal This looks like the error message of MSVC or some other compiler that isn't gcc. That's not going to work, you must use gcc. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?
On Thu, 12 Jan 2006, Joshua Daniel Franklin wrote: On 1/11/06, Igor Peshansky wrote: Hi, I believe I'm up-to-date with xmlto and DocBook on Cygwin. Still, I was unable to build either the user's guide or the FAQ from sources. Part of the problem was a bug in doctool.c (for which I'll send a patch to cygwin-patches shortly). However, even with that bug fixed, I got the following error: I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd /usr/src/cygwin-cvs/build/i686-pc-cygwin/winsup/doc/cygwin-ug-net.sgml:3: warning: failed to load external entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;[] ^ (with a bunch of other errors about undefined entities, which, I believe, followed from the above). I traced this down to the /usr/bin/xmlto, which invokes xsltproc with the --nonet option. A question to the xmlto maintainer: is there a particular reason this option is being used? Obviously somebody was able to successfully build the FAQ and User's guide. Was this using Cygwin? If so, what versions of xmlto and the various DocBook packages were used? I build everything but the PDFs on Cygwin. Is your issue related to http://www.cygwin.com/ml/cygwin-apps/2005-10/msg00065.html I.e., you have docbook-xml42 installed? It might help to send info as at http://www.cygwin.com/problems.html And indeed it was. Installing the various docbook-xml* packages let me build off the net without hacking xmlto. Thanks. I could've sworn I took care of it back in October, but looks like it slipped through the cracks. There might still be utility in controlling whether or not the build is network-aware via xmlto parameters (at the moment, there is no way to turn off the --nonet option). I should submit a feature request at some point. Did you happen to take a look at the FAQ rewording I proposed (http://cygwin.com/ml/cygwin-patches/2006-q1/msg00016.html)? Was cygwin-patches the correct list for it, or should it have been sent here? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problems with unistd.h
Burcu Ozserim schrieb: I get the following error while compiling flite. Is this a Cygwin problem? You are not using cygwin. Here flite compiles just fine in cygwin, assuming we are talking about the speech synthesis program. Configuration: flite - Win32 Debug Compiling... au_none.c c:\cygwin\usr\include\mingw\unistd.h(23) : error C2081: 'off_t' : name in formal parameter list illegal -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Updated: inetutils-1.3.2-34 [setsockopt TOS (ignored): Protocol not available]
Hi Corinna, Thanks for the inetutils update. The inetd -D option is particularly welcome (so thanks also to Bryan Thrall). Unfortunately the new version's ftp, rcp, and rlogin commands give an annoying new warning when connecting, eg. ftp: setsockopt TOS (ignored): Protocol not available Actually, I suspect this is due to being compiled against updated headers, because I got the same when recompiling an earlier version of inetutils. Perhaps the IP_TOS (or similar) definition was added (since you built inetutils last), even though it doesn't seem to be implemented in setsockopt (for my XP SP2 system). I assume the messages can be ignored, but it would be good if they could be supressed. Thanks, Tim. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: 11 January 2006 16:30 To: cygann Subject: Updated: inetutils-1.3.2-34 I've updated the version of inetutils to 1.3.2-34. Unfortunately I found that I had a longstanding build problem on my local machine, which could result in stuff like rlogind bombing with a segmentation violation and similar funny problems. However, since a release without some interesting change is too boring, here we go: Changes in 1.3.2-34: - Forced rebuild to fix longstanding(?) local build problem. - Change syslogd-config script to deal with existing syslog-ng installation, in preparation of upcoming syslog-ng package. == === IMPORTANT NOTE: - When updating inetutils, take care that syslogd.exe, inetd.exe and subsequent processes don't run anymore. Otherwise the update will fail. == === === cut here == Tim Adye [EMAIL PROTECTED] http://hepunx.rl.ac.uk/~adye BaBar Group, Particle Physics Dept, Rutherford Appleton Lab, UK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: once more unto the breech - please try a snapshot so I can release this thing
On Wed, Jan 11, 2006 at 10:46:24PM -0800, Yitzchak Scott-Thoennes wrote: Just in case it's relevant, note that I have experimental bash, readline, libreadline6, findutils, and coreutils. Does the latest snapshot behave any differently? Neither Corinna nor I can duplicate this problem so neither of us can do anything other than shoot in the dark to try to solve it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated Cygwin Package: fetchmail-6.3.1-1
Pavel, On Thu, Jan 12, 2006 at 05:59:57PM +0200, Pavel Tsekov wrote: On Wed, 4 Jan 2006, Jason Tishler wrote: New News: === I have updated the version of fetchmail to 6.3.1-1. The tarballs should be available on a Cygwin mirror near you shortly. The only change between this version and the previous one is the following: o update to version 6.3.1 I've updated fetchmail today and I no longer get visual feedback about its progress when messages are being retrieved. Instead printing on the terminal the information is recorder in the Event log. Sounds like the way you are using fetchmail is interacting with syslog. Is this expected ? I'm not sure. FWIW, I am using fetchmail configured to run as a daemon under cygrunsrv and my output is still going to my log file as before. So, I haven't noticed any differences between 6.2.5 and 6.3.1. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?
On 1/12/06, Igor Peshansky wrote: On Thu, 12 Jan 2006, Joshua Daniel Franklin wrote: I build everything but the PDFs on Cygwin. Is your issue related to http://www.cygwin.com/ml/cygwin-apps/2005-10/msg00065.html I.e., you have docbook-xml42 installed? It might help to send info as at http://www.cygwin.com/problems.html And indeed it was. Installing the various docbook-xml* packages let me build off the net without hacking xmlto. Thanks. I could've sworn I took care of it back in October, but looks like it slipped through the cracks. There might still be utility in controlling whether or not the build is network-aware via xmlto parameters (at the moment, there is no way to turn off the --nonet option). I should submit a feature request at some point. Might be an upstream issue, too. I haven't looked at the Cygwin-specific xmlto patches if there are any. Did you happen to take a look at the FAQ rewording I proposed (http://cygwin.com/ml/cygwin-patches/2006-q1/msg00016.html)? Was cygwin-patches the correct list for it, or should it have been sent here? That was the right place, I'm just a little behind. I've applied it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: nfs-server-2.3-4
Where is a mirror I can download this from? I tried a few but they only had 2.3-3. Thanks, Siegfried -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robb, Sam Sent: Thursday, January 12, 2006 1:50 PM To: cygwin@cygwin.com Subject: [ANNOUNCEMENT] Updated: nfs-server-2.3-4 I've updated the nfs-server package for Cygwin to version 2.3-4. This release corrects a problem with trying to assign to a reserved shell variable in the nfs-server-config script. *** INSTALLATION *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. - Sam Robb ([EMAIL PROTECTED]) - http://www.timesys.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
