Mark Geisert | 31 Dec 06:35 2013

[PATCH] FAQ update: packages needed to build Cygwin

Hope I'm doing this correctly.  Here is the ChangeLog entry followed by 
the patch.  I wasn't sure if patch originator or patch committer, if 
different, gets their name in the ChangeLog entry.  Patch rationale 
available on request.
Cheers,

..mark

====

2013-12-31  Mark Geisert  <mark <at> maxrnd.com>

 	* faq-programming.xml: Update packages needed to build Cygwin.

====

Index: faq-programming.xml
===================================================================
RCS file: /cvs/src/src/winsup/doc/faq-programming.xml,v
retrieving revision 1.27
diff -u -r1.27 faq-programming.xml
--- faq-programming.xml 5 Jun 2013 07:57:39 -0000       1.27
+++ faq-programming.xml 31 Dec 2013 05:25:33 -0000
 <at>  <at>  -693,11 +693,19  <at>  <at> 
  <answer>

  <para>First, you need to make sure you have the necessary build tools
-installed; you at least need <literal>gcc</literal>, <literal>make</literal>,
-<literal>perl</literal>, and <literal>cocom</literal>. If you want to run
-the tests, <literal>dejagnu</literal> is also required.
(Continue reading)

James Johnston | 25 Dec 00:01 2013

Patch to optionally disable overlapped pipes

Hi,

As I have recently mentioned on the main Cygwin mailing list, Cygwin by
default creates FILE_FLAG_OVERLAPPED named pipes for the standard file
handles (stdin/stdout/stderr).  These overlapped pipes require all programs
using ReadFile/WriteFile to use overlapped I/O when using the pipes.  Since
standard runtimes in Win32 programs don't normally use overlapped I/O on the
standard file handles, most Win32 programs will exhibit undefined behavior
when called by Cygwin.  In my case, it has resulted in a problem with
calling .NET Framework 4.0 programs from Cygwin (which, coincidentally,
NETFX 4.0 also probably has a bug resulting in undefined behavior that
definitely clashes with overlapped pipes).

The attached patch creates a new "pipe_nooverlap" flag in the CYGWIN
environment variable (similar to the existing pipe_byte flag).  By default,
the flag would not be set and Cygwin will continue to make overlapped pipes
by default, because I did not know if this will result in any breakages
elsewhere in some Cygwin packages.

If the new "pipe_nooverlap" flag is set, then Cygwin won't make overlapped
pipes by default (i.e. pipes made by the pipe or pipe2 functions).  For me,
this got NETFX 4.0 programs working again.  I've been using it all day today
with no ill effects noted.  It seems safe to use.  But I made it a flag
because I am not 100% certain that some package won't break, and it isn't
needed if you are only running Cygwin programs (which presumably use
Cygwin1.dll which presumably is using overlapped I/O everywhere).

If the maintainers feel that a CYGWIN flag isn't necessary and it is safe to
always remove FILE_FLAG_OVERLAPPED, then I can submit a patch that doesn't
have the "pipe_nooverlap" flag - i.e. just assumes the flag is always set.
(Continue reading)

Ray Donnelly | 22 Dec 02:03 2013
Picon

[PATCH] Reattach trailing dirsep on existing directories too.

I hope this is OK and I've done it in the best place. Please advise if
it needs any changes.
Ray Donnelly | 22 Dec 01:40 2013
Picon

[PATCH] Fix potentially uninitialized variable p


Ray Donnelly | 22 Dec 01:39 2013
Picon

[PATCH] Fix some debug string format specifiers.

I hope patches generated with git are OK?

Best regards,

Ray.
Jon TURNEY | 13 Nov 15:37 2013
Picon

[PATCH] Prototype initstate() etc. if _XOPEN_SOURCE is defined appropriately


Not sure if this is wanted, but mesa likes to compile with '-std=c99
D_XOPEN_SOURCE=500', which leads to exciting crashes on x86_64 because
initstate() is not prototyped.

2013-11-13  Jon TURNEY  <jon.turney <at> dronecode.org.uk>

	* include/cygwin/stdlib.h(initstate, random, setstate, srandom) :
	Prototype if not __STRICT_ANSI__ or _XOPEN_SOURCE is defined appropriately.
Index: cygwin/include/cygwin/stdlib.h
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/stdlib.h,v
retrieving revision 1.13
diff -u -u -p -r1.13 stdlib.h
--- cygwin/include/cygwin/stdlib.h	21 May 2013 19:04:49 -0000	1.13
+++ cygwin/include/cygwin/stdlib.h	13 Nov 2013 14:28:35 -0000
 <at>  <at>  -31,10 +31,14  <at>  <at>  void	setprogname (const char *);
 char *realpath (const char *, char *);
 char *canonicalize_file_name (const char *);
 int unsetenv (const char *);
+#endif /*__STRICT_ANSI__*/
+#if !defined(__STRICT_ANSI__) || (_XOPEN_SOURCE >= 500) || (defined(_XOPEN_SOURCE) && defined(_XOPEN_SOURCE_EXTENDED))
 char *initstate (unsigned seed, char *state, size_t size);
 long random (void);
 char *setstate (const char *state);
 void srandom (unsigned);
+#endif
+#ifndef __STRICT_ANSI__
(Continue reading)

Eric Blake | 26 Sep 01:26 2013
Picon

fix off-by-one in dup2

Solves the segfault here: http://cygwin.com/ml/cygwin/2013-09/msg00397.html
but does not address the fact that we are still screwy with regards to
rlimit.

======
Ultimately, based on my understanding of POSIX and glibc, my goal is to
have a number of changes (this patch only scratches the surface; there's
more to go):

dtable.h tracks soft and hard limits, inherited over fork and preserved
across exec

hard limit starts at OPEN_MAX_MAX and can only be reduced
soft limit starts at hard limit, and can be reduced to _POSIX_OPEN_MAX (8)
dtable.size starts at MAX(32, fork/exec size)

getdtablesize() and sysconf(_SC_OPEN_MAX) always returns the soft limit,
as in glibc and permitted by POSIX (_SC_OPEN_MAX is the only sysconf
variable that can be runtime dynamic)

dtable.size is decoupled from soft limit, and is guaranteed to be <=
hard limit.  It can grow up to current soft limit; but soft limit can
later be reduced lower than dtable.size (glibc does this); on fork and
exec, we are careful to still allow fds beyond the current soft limit.

getrlimit(RLIMIT_NOFILE, &r) => returns soft and hard limits from dtable
rather than hard limit as a constant and soft limit as current dtable.size

setrlimit(RLIMIT_NOFILE, &r) => cannot set hard limit to unlimited; soft
limit of unlimited is translated to current hard limit; hard limit
(Continue reading)

Paul Kunysch | 25 Sep 12:41 2013
Picon

Re: Fix sem_getvalue

> That looks like a reasonable fix.  Did you trace through all of the
> callers of semaphore::_getvalue to make sure that some of them aren't
> relying on the old behavior?

I did not look for other callers.

I just wrote a very simple test for sem_getvalue() and copied different 
cygwin1.dll versions to my test-application.
-- 

Kunysch, Paul
Software Development

emsys Embedded Systems GmbH
Werner von Siemens Str. 20
98693 Ilmenau
Germany

Tel.: +49 3677 68977-16   Fax: +49 3677 68977-19
E-Mail: paul.kunysch <at> emsys.de
Internet: www.emsys.de

CEO: Dr.-Ing. Karsten Pahnke
office: Ilmenau
Register of commerce in county court Jena: HRB 304988

Attachment (smime.p7s): application/pkcs7-signature, 5389 bytes
Paul Kunysch | 18 Sep 11:53 2013
Picon

Fix sem_getvalue

Hello

In 1.7.24 and 1.7.25 sem_getvalue() returns the current value instead of 
setting the out-parameter and returning 0/-1 for success/error.

I attached a simple fix.

I don't know if this should be further improved by setting errno to 
EINVAL if STATUS_INVALID_HANDLE == status.

Unfortunately I wasn't able to run and extend the unit tests.  Running 
"make check" fails with "No rule to make target `dataascii.o', needed by 
`libltp.a'".  The VPATH seems to be extended correctly.

Kind regards,
Paul
--

-- 

Kunysch, Paul
Software Development

emsys Embedded Systems GmbH
Werner von Siemens Str. 20
98693 Ilmenau
Germany

Tel.: +49 3677 68977-16   Fax: +49 3677 68977-19
E-Mail: paul.kunysch <at> emsys.de
Internet: www.emsys.de

(Continue reading)

Yaakov (Cygwin/X | 13 Sep 19:10 2013
Picon
Picon

[PATCH] cygcheck: xz packages

cygcheck needs fixing wrt .tar.xz packages; patch attached.

Yaakov
Attachment (cygcheck-xz-pkgs.patch): text/x-patch, 675 bytes
Yaakov (Cygwin/X | 24 Jun 07:17 2013
Picon
Picon

[PATCH] Export rawmemchr

Patch for Cygwin, pending approval of my newlib patch, attached.

Yaakov
Attachment (cygwin-rawmemchr.patch): text/x-patch, 2367 bytes

Gmane