RE: [ANNOUNCEMENT] Updated: nfs-server-2.3-4

[Siegfried Heintze]

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/

Re: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?

[Joshua Daniel Franklin]

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
> ()?  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 Cygwin Package: fetchmail-6.3.1-1

[Jason Tishler]

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: once more unto the breech - please try a snapshot so I can release this thing

[Christopher Faylor]

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: Updated: inetutils-1.3.2-34 [setsockopt TOS (ignored): Protocol not available]

[Adye, TJ \(Tim\)]

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: problems with unistd.h

[Holger Krull]

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: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?

[Igor Peshansky]

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
()?  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

[Brian Dessent]

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: Define _POSIX_SOURCE in cygwin's features.h?

[Samuel Thibault]

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 
#include 
#include 
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: Errors building the FAQ/User's Guide (Attn: xmlto maintainer)?

[Joshua Daniel Franklin]

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/

problems with unistd.h

[Burcu Ozserim]

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: Perl/TK Missing Dependency Found

[Brett Serkez]

> > 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
> > () 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/

Re: Perl/TK Missing Dependency Found

[Yaakov S (Cygwin Ports)]

-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
> () 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/

inetutils-1.3.2-34: setsockopt warning from ftp

[David Rothenberger]

\cygruby18.dll - os=4.0 img=1.0 sys=4.0
  "cygruby18.dll" v0.0 ts=2005/10/7 0:56
   78k 2004/10/13 c:\cygwin\bin\cygsasl2-2.dll - os=4.0 img=1.0 sys=4.0
  "cygsasl2-2.dll" v0.0 ts=2004/10/13 15:50
  129k 2005/08/15 c:\cygwin\bin\cygspeex-1.dll - os=4.0 img=1.0 sys=4.0
  "cygspeex-1.dll" v0.0 ts=2005/8/15 2:57
  231k 2005/10/17 c:\cygwin\bin\cygssl-0.9.7.dll - os=4.0 img=1.0 sys=4.0
  "cygssl-0.9.7.dll" v0.0 ts=2005/10/17 2:16
  215k 2005/10/11 c:\cygwin\bin\cygssl-0.9.8.dll - os=4.0 img=1.0 sys=4.0
  "cygssl-0.9.8.dll" v0.0 ts=2005/10/11 5:47
  304k 2005/07/10 c:\cygwin\bin\cygtiff-5.dll - os=4.0 img=1.0 sys=4.0
  "cygtiff-5.dll" v0.0 ts=2005/7/10 16:18
  281k 2003/02/24 c:\cygwin\bin\cygtiff3.dll - os=4.0 img=1.0 sys=4.0
  "cygtiff3.dll" v0.0 ts=2003/2/23 20:58
  282k 2003/08/11 c:\cygwin\bin\cygtiff4.dll - os=4.0 img=1.0 sys=4.0
  "cygtiff4.dll" v0.0 ts=2003/8/10 19:32
  281k 2005/07/10 c:\cygwin\bin\cygtiffxx-5.dll - os=4.0 img=1.0 sys=4.0
  "cygtiffxx-5.dll" v0.0 ts=2005/7/10 16:21
   27k 2005/10/23 c:\cygwin\bin\cygungif-4.dll - os=4.0 img=1.0 sys=4.0
  "cygungif-4.dll" v0.0 ts=2005/10/23 13:11
  174k 2005/08/14 c:\cygwin\bin\cygvorbis-0.dll - os=4.0 img=1.0 sys=4.0
  "cygvorbis-0.dll" v0.0 ts=2005/8/14 12:15
 1125k 2005/08/14 c:\cygwin\bin\cygvorbisenc-2.dll - os=4.0 img=1.0 sys=4.0
  "cygvorbisenc-2.dll" v0.0 ts=2005/8/14 12:20
   42k 2005/08/14 c:\cygwin\bin\cygvorbisfile-3.dll - os=4.0 img=1.0 sys=4.0
  "cygvorbisfile-3.dll" v0.0 ts=2005/8/14 12:20
  314k 2005/08/10 c:\cygwin\bin\cygwmf-0-2-7.dll - os=4.0 img=1.0 sys=4.0
  "cygwmf-0-2-7.dll" v0.0 ts=2005/8/10 6:54
  150k 2005/08/10 c:\cygwin\bin\cygwmflite-0-2-7.dll - os=4.0 img=1.0 sys=4.0
  "cygwmflite-0-2-7.dll" v0.0 ts=2005/8/10 6:53
 3006k 2003/10/12 c:\cygwin\bin\cygxerces-c23.dll - os=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

Re: Perl/TK Missing Dependency Found (Attn: libfontconfig maintainer)

[Christopher Faylor]

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/

Re: Perl/TK Missing Dependency Found (Attn: libfontconfig maintainer)

[Brett Serkez]

> > > 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)

[Igor Peshansky]

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/

[ANNOUNCEMENT] Updated: nfs-server-2.3-4

[Robb, Sam]

  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: Define _POSIX_SOURCE in cygwin's features.h?

[Christopher Faylor]

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
>).

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  (which is also called by
>, 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/

Re: Define _POSIX_SOURCE in cygwin's features.h?

[Yaakov S (Cygwin Ports)]

-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 ).

> 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  (which is also called by
, 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
.

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: nfs-server-config died (Attn: nfs-server maintainer)

[Robb, Sam]

> 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: Perl/TK Missing Dependency Found

[Brett Serkez]

> 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: Define _POSIX_SOURCE in cygwin's features.h?

[Christopher Faylor]

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: Define _POSIX_SOURCE in cygwin's features.h?

[Dave Korn]

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?

[Christopher Faylor]

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]

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?

[Christopher Faylor]

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?

[Christopher Faylor]

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?

[Dave Korn]

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?

[Samuel Thibault]

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]

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]

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?

[Dave Korn]

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?

[Yaakov S (Cygwin Ports)]

-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?

[Samuel Thibault]

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: problem with cron

[Holger Krull]

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?

[Christopher Faylor]

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: Define _POSIX_SOURCE in cygwin's features.h?

[Dave Korn]

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: problems with running Gnome applications

[Yaakov S (Cygwin Ports)]

-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/

Define _POSIX_SOURCE in cygwin's features.h?

[Christopher Faylor]

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: once more into the breach - please try a snapshot so I can release this thing

[Corinna Vinschen]

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/

Re: [ANNOUNCEMENT] [ANNOUNCEMENT] Updated: fftw3-3.0.1-2

[Christopher Faylor]

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: problems with running Gnome applications

[Christopher Faylor]

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: bash 3.1-1 "exec -l" doesn't start login shell

[David Rothenberger]

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: [ANNOUNCEMENT] Updated Cygwin Package: fetchmail-6.3.1-1

[Pavel Tsekov]

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: CLISP 2.37 is really 2.36?

[Sam Steingold]

> * 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: nfs-server-config died (Attn: nfs-server maintainer)

[Igor Peshansky]

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: problems with running Gnome applications

[Alessandro Lendaro]

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/

nfs-server-config died

[Hiroki Sakagami]

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/

config error with Apache2 package

[Stefan Sabolowitsch]

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/

Re: [ANNOUNCEMENT] [ANNOUNCEMENT] Updated: fftw3-3.0.1-2

[James R. Phillips]

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/

RE: problems with running Gnome applications

[Dave Korn]

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: autoconf/automake problem: simple testcase [was RE: autoconf/automake: just can't get it to work at all.]

[Dave Korn]

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?

  

  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/

problems with running Gnome applications

[Alessandro Lendaro]

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/