Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/07/2017 06:36 PM, David Billinghurst wrote:

On 8/03/2017 10:25, Daniel Santos wrote:

My concern is with the dynamic portion of this behavior -- what is 
affected by environment variables.


Many years ago I ran a nightly build/test of gcc under cygwin and 
reported the results to gcc-testresults.  There may be is discussion 
on the gcc mailing lists from c2000-2005.  If you search 
"site:gcc.gnu.org David Billinghurst cygwin" you ??might?? find 
something relevant.


From memory, I got it all working by

 * building gcc and friends
 * using find to locate all the .exe and .dll files in the build tree
 * worked out by trial and error which files were needed at run time by
   the test suite.
 * setting PATH when running the testsuite so that the directories
   containing (new) required .exe and .dll were in front of any system
   directories
 * making sure that PATH wasn't reset by the testsuite
 * looking at places where LD_LIBRARY_PATH was set/modified by the
   testsuite and checking if cygwin needed PATH to match
 * (submitting patched to fix gcc testsuite under cygwin)

Once that was done it all "just worked" until it broke again. Good luck.



Thank you very much for this. This is the path that I was kind-of 
setting off on, I just wanted to try one more time to run the tests 
as-is, this time with only one make job and see if I could get the mass 
of failures to match so that I could say that my patches cause "no 
additional errors" (ignoring the fact that there's 16k total failures), 
but I can't even get the breakages to match up.  (This is another topic, 
when I run tests in parallel I eventually end up with some "broken pipe" 
errors and that make job hangs).


I found some of your patches, pity it got re-broken.  I have a bug open 
for this here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867.  In 
the end, I think that this should be fixed by adding some new "black 
box" interfaces to DejaGnu that manage the executable and library search 
paths.  Then gcc's testsuite should deprecate ANY direct access to any 
of the *PATH environment variables in favor of this new interface in 
DejaGnu.  As it is, the gcc code already changes both LD_LIBRARY_PATH 
and SHLIB_PATH to support HP-UX (not sure if any other systems use the 
latter), so it's already gotten a little hairy.


In order to facilitate this cleanly, I think that libgcc needs to be 
moved out of /usr/bin and into /usr/lib/gcc/// and 
then have that added to the PATH and LD_LIBRARY_PATH somewhere 
(autoexec.bat? registry? I have no idea).  Having an /sbin/ldconfig 
would be the most ideal mechanism of managing this. (Anybody want a 
little project? :)  The test harness regularly toggles in between the 
host and target compiler.


We need a clean and reproducible set of steps for running tests on 
Cygwin.  Somewhere, these tests should be run regularly, maybe on a 
server/compiler farm somewhere under a VM, so that breakages can be 
addressed as soon as they appear rather than when somebody wants to 
touch the ms_abi code and has to test on Cygwin -- how I ended up here. :)


Thanks again for the help!
Daniel

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Symlink file size

[Ken Brown]

On 3/7/2017 10:37 PM, Steven Penny wrote:

Cygwin seems to have no way to print an accurate size of a symlink.
Consider
this command:

   $ touch alfa.txt
   $ CYGWIN= ln -s alfa.txt bravo.txt

Now cmd.exe can print the correct size just fine:

   > dir /AS
   2017-03-07  09:26 PM30 bravo.txt

However Cygwin prints incorrect 8 bytes with ls:

   $ ls -l
   total 2
   -rw-r--r-- 1 Steven None 0 Mar  7 21:26 alfa.txt
   lrwxrwxrwx 1 Steven None 8 Mar  7 21:26 bravo.txt -> alfa.txt


8 is the length of the file name "alfa.txt".  From 
https://linux.die.net/man/2/stat:  "The size of a symbolic link is the 
length of the pathname it contains, without a terminating null byte."


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Symlink file size

[Steven Penny]

Cygwin seems to have no way to print an accurate size of a symlink. Consider
this command:

   $ touch alfa.txt
   $ CYGWIN= ln -s alfa.txt bravo.txt

Now cmd.exe can print the correct size just fine:

   > dir /AS
   2017-03-07  09:26 PM30 bravo.txt

However Cygwin prints incorrect 8 bytes with ls:

   $ ls -l
   total 2
   -rw-r--r-- 1 Steven None 0 Mar  7 21:26 alfa.txt
   lrwxrwxrwx 1 Steven None 8 Mar  7 21:26 bravo.txt -> alfa.txt

and stat:

   $ stat --format %s bravo.txt
   8

and du:

   $ du -b bravo.txt
   8   bravo.txt

and find:

   $ find bravo.txt -printf %s
   8

wc seems to draw from the source file:

   $ wc -c bravo.txt
   0 bravo.txt

What gives?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: tar 1.29 regression, duplicating files with -T and --no-recursion

[Tony Kelman]

> $ tar -czf test.tar.gz -T tartest/filelist.txt --no-recursion

Looks like this was an intentional change: 
http://lists.gnu.org/archive/html/bug-tar/2016-05/msg8.html
--no-recursion is apparently positional, so the fact that this worked before
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=163e96a0e619a900eab6de827c7c5749ecc9d3f2
may have been accidental. As of 
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=9a33077a7b7ad7d32815a21dee54eba63b38a81c
(the very first commit after 1.29), this invocation now gives an error.
Guess no action is needed.

-Tony

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Changing behaviour of pthread_cond_wait().

[Takashi Yano]

On Tue, 7 Mar 2017 15:33:06 +0100 Corinna Vinschen wrote:

> I applied a patch to change the behaviour as proposed, and uploaded
> new snapshots to https://cygwin.com/snapshots/ for testing.

Confirmed. Thanks much.

-- 
Takashi Yano 

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Strange errors running gcc tests on Cygwin

[David Billinghurst]

On 8/03/2017 10:25, Daniel Santos wrote:

My concern is with the dynamic portion of this behavior -- what is 
affected by environment variables.


Many years ago I ran a nightly build/test of gcc under cygwin and 
reported the results to gcc-testresults.  There may be is discussion on 
the gcc mailing lists from c2000-2005.  If you search "site:gcc.gnu.org 
David Billinghurst cygwin" you ??might?? find something relevant.


From memory, I got it all working by

 * building gcc and friends
 * using find to locate all the .exe and .dll files in the build tree
 * worked out by trial and error which files were needed at run time by
   the test suite.
 * setting PATH when running the testsuite so that the directories
   containing (new) required .exe and .dll were in front of any system
   directories
 * making sure that PATH wasn't reset by the testsuite
 * looking at places where LD_LIBRARY_PATH was set/modified by the
   testsuite and checking if cygwin needed PATH to match
 * (submitting patched to fix gcc testsuite under cygwin)

Once that was done it all "just worked" until it broke again. Good luck.





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

tar 1.29 regression, duplicating files with -T and --no-recursion

[Tony Kelman]

Test case:


Tony@LAPTOP-O230JCFF ~
$ tar --version
tar (GNU tar) 1.29
Packaged by Cygwin (1.29-1)
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Tony@LAPTOP-O230JCFF ~
$ mkdir tartest

Tony@LAPTOP-O230JCFF ~
$ echo 'tartest' > tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ echo 'tartest/filelist.txt' >> tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ tar -czf test.tar.gz -T tartest/filelist.txt --no-recursion

Tony@LAPTOP-O230JCFF ~
$ tar -tf test.tar.gz
tartest/
tartest/filelist.txt
tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ ls -al test.tar.gz
-rw-r--r-- 1 Tony None 186 Mar  7 15:39 test.tar.gz



If I downgrade to tar 1.28, I instead get

Tony@LAPTOP-O230JCFF ~
$ tar -tf test.tar.gz
tartest/
tartest/filelist.txt

Tony@LAPTOP-O230JCFF ~
$ ls -al test.tar.gz
-rw-r--r-- 1 Tony None 177 Mar  7 15:38 test.tar.gz



... though I just checked in a docker container of Debian unstable which
has tar 1.29 and I see the same issue, so this isn't cygwin-specific
and maybe I should report it upstream.

-Tony

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Strange errors running gcc tests on Cygwin

[Daniel Santos]

On 03/07/2017 07:58 AM, cyg Simple wrote:

On 3/6/2017 9:03 PM, Daniel Santos wrote:

On 03/05/2017 05:08 AM, David Billinghurst wrote:

No.

LD_LIBRARY_PATH is used by dlopen ().

PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx

Thank you for this clarification.  So load-time dlls are resolved (in
ntdll.exe or some such) using PATH and run-time dlls loaded with
dlopen() are resolved with LD_LIBRARY_PATH?  I'm obviously not intimate
with Cygwin's architecture, but I'm guessing that explicitly using
LoadLibrary is still going to use PATH.

You're obviously not intimate with Windows either.  The search algorithm
in Windows is more involved than PATH.  You need to study more.

My concern is with the dynamic portion of this behavior -- what is 
affected by environment variables.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

pthread_create() slowdown with concurrent sched_yield()

[Dan Bonachea]

I suspect I may have discovered a corner-case performance bug in
Cygwin's pthread_create() implementation. The problem arises when a
call to pthread_create() is made concurrently with multiple pthreads
in the same process spinning on calls to sched_yield(). I've searched
the Cygwin mailing list archives, user guide, FAQ, and Google and not
found any mention of this particular misbehavior.

A minimal demo program is copied below and also available here:
   https://upc-bugs.lbl.gov/bugzilla/attachment.cgi?id=549
The demo program is a narrowed-down version of test code used in the
GASNet communication system (http://gasnet.lbl.gov).

The test code calls pthread_create to spawn a user-controlled number
of threads, which then execute 1000 "spin barriers" - implemented by
spinning on in-memory flags and stalling with sched_yield(). The test
can also optionally insert a pthread_barrier_wait() across all threads
before the first spin barrier.

Here are some experimental results - these are full-process "real"
wall-clock timings (fastest over 5 runs) collected using the bash
'time' shell built-in. The systems are otherwise idle.  All code has
been compiled with the default 64-bit /usr/bin/gcc (compile line
appears as a comment in the test), but the results are similar with
clang.

  8-core Win7-Cygwin/64 2.6.0 8-core Linux/64 3.13.0 (Ubuntu)
 i7-4800MQ @ 2.70GHz Xeon E5420 @ 2.50GHz
  4 core x 2-way hyperthread   2 socket x 4 cores/socket
threadcreate-vs-create-vs- create-vs-create-vs-
countspin/yieldpthread_barrierspin/yieldpthread_barrier
--       - -
1 0m 0.000s   0m0.000s  0m0.001s   0m0.001s
2 0m 0.000s   0m0.000s  0m0.002s   0m0.002s
4 0m 0.000s   0m0.000s  0m0.002s   0m0.003s
8 0m 0.000s   0m0.016s  0m0.003s   0m0.006s
160m10.717s   0m0.000s  0m0.013s   0m0.012s
322m23.988s   0m0.016s  0m0.018s   0m0.024s
64   12m40.002s   0m0.016s  0m0.038s   0m0.046s
128 >20m* 0m0.016s  0m0.063s   0m0.067s
256 >20m* 0m0.047s  0m0.290s   0m0.631s
(*) = killed after >20m of wall time (>2.5 hours of cpu time)

When the number of pthreads start to exceed the physical core count,
Cygwin's pthread_create() starts taking exponentially longer to return
when it is competing with concurrent calls to sched_yield(). During
the long pauses, windows Task Manager shows the process consuming 100%
CPU on all cores and it becomes unresponsive to SIGINT. The observed
behavior seems to suggest that Cygwin's pthread creation operation
(and/or the newly spawned thread) is not being scheduled, despite
every OTHER application thread spamming calls to sched_yield().

If the other threads competing with pthread_create() are instead
stalled in a pthread_barrier_wait(), the problem goes away entirely
(ie by adding a semantically unnecessary pthread_barrier_wait(), the
worst-case performance gets over 75,000x better). The test results
demonstrate that the spin barriers themselves run quite fast, but
pthread_create() runs very slowly when other unrelated threads are
executing sched_yield(). Note that inserting pthread_barrier_wait() to
stall every thread in the process during a pthread_create() is not
always a practical solution in a real program, where the thread
creation behavior may be less regular than shown in this example.

Also shown are performance results for the same test on a Linux system
with somewhat comparable hardware (the CPU running Linux is 5 years
older on Intel's product calendar). The Linux system does NOT
demonstrate the problem. Similar code has run on several other POSIX
OS's (including OSX, FreeBSD, NetBSD, Solaris), in a wide variety of
architectural configurations -- all without problems.

This pthread_create() performance problem has been reproduced with
similar results on four different windows machines (including laptops
and servers), running all combinations of the following Cygwin
configurations:
  Windows 7/64 Cygwin {32,64} {2.7,2.6,2.0}
  Windows 10/64 Cygwin 64 2.7

I realize this may represent a parallelism pattern that cannot be
supported efficiently on Cygwin (and we've internally found an
app-specific workaround not represented here), but I thought it
responsible to report the performance issue anyhow.

Thanks for your consideration.

-Dan Bonachea



// pthread-spawn.c test, by Dan Bonachea
// compile with a command like:
//   gcc -std=c99 -D_REENTRANT -D_GNU_SOURCE pthread-spawn.c -o
pthread-spawn -lpthread
// usage:
//   pthread-spawn   

#include 
#include 
#include 
#include 


int numthreads=256;
int numiters=1000;
int initialbarrier = 0;

pthread_barrier_t pthbar

Re: Failed password for invalid user

[Corinna Vinschen]

On Mar  6 09:48, jesus san miguel wrote:
> Hi Andrey,
> 
> Thanks for your answer, but I am using password-less authentication
> too (with public/private keys), so /etc/password is necessary, isn't
> it?

No!  Who told you that?  As long as you use the user account name
the way it's called in Cygwin (`getent passwd ...' is helpful), and
as long as you use it case-sensitive when logging in via ssh, you
doe't need /etc/passwd.  You only need this file to cover special 
cases like using different names for the same user account.

Please have a look into http://cygwin.com/cygwin-ug-net/ntsec.html.

It's pretty much all explained there.  Well, except for the fact that
OpenSSH handles the username case-sensitive, but that's an OpenSSH
issue, not a Cygwin issue.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Failed password for invalid user

[Corinna Vinschen]

On Mar  3 10:03, jesus san miguel wrote:
> I am running cygwin 2.7.0 sshd service under a local cyg_server account.
> 
> I wanted to avoid case sensitive problems by duplicating users in
> /etc/passwd, but I find mixed results:
> I can login as "Administrator", "MYPC+Administrator" and "miabuela",
> but not as "administrator" despite all of them being the same Window
> user.
> 
> This is an excerpt of /etc/passwd:
> 
> $ cat /etc/passwd | grep 500
> SSFE009W2012+Administrator:*:197108:197121:U-SSFE009W2012\Administrator,S-1-5-21-3863157116-1840367147-1613345037-500:/home/Administrator:/bin/bash
> miabuela:*:197108:197121:U-SSFE009W2012\Administrator,S-1-5-21-3863157116-1840367147-1613345037-500:/home/Administrator:/bin/bash
> Administrator:*:197108:197121:U-SSFE009W2012\Administrator,S-1-5-21-3863157116-1840367147-1613345037-500:/home/Administrator:/bin/bash
> administrator:*:197108:197121:U-SSFE009W2012\Administrator,S-1-5-21-3863157116-1840367147-1613345037-500:/home/Administrator:/bin/bash
> 
> #Administrator@SSFE009W2012 /etc
> $ uname -a
> CYGWIN_NT-6.3-WOW SSFE009W2012 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin
> 
> The error I get in windows log is "Failed password for invalid user
> administrator"
> 
> 
> Thanks in advance,
> Jesus

OpenSSH checks the username case-sensitive!

So, depending on the order in /etc/passwd you can login either with
"Administrator" or with "administrator", whatever comes first and
matches the user account.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Failed password for invalid user

[cyg Simple]

On 3/6/2017 4:22 AM, Andrey Repin wrote:
> Greetings, jesus san miguel!
> 
>> Besides, user alias "miabuela" is working as expected. Why shouldn't
>> "administrator" alias work as well?
> 
> That's the worst idea I've heard since morning.
> 

It's a legacy idea to allow different users control a password to the
same uid.  Not a bad idea but certainly not a secure one as needed for
today. It's still a valid idea depending on what the uid is used for.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Profile XXXXX failed to execute.

[cyg Simple]

On 3/6/2017 6:11 AM, Nilesh Shedge wrote:
> Can you please enlist the file which I need to replace?
> 

See http://cygwin.com and download the most recent setup.exe for your
platform system (32bit vs 64bit).  It will know what to update.

> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html

If that fails then see the above.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Perl: Can't compile Module::Build::Tiny (required by Perl::Critic)

[Jim Reisert AD1C]

On Mon, Mar 6, 2017 at 11:52 AM, Achim Gratz  wrote:

> Most likely a new test.  Testing for read-only status quite often doesn't work
> as expected on Windows due to write/change access being granted by some DACL
> somewhere up the directory chain (or when you are in the Administrators
> group or some other group with similar access rights).  The module
> builds just fine for me, BTW (but then I'm not using cpan).  Ignore the
> failing test and force install.

Thanks, Achim.  I have Perl::Critic installed now.

-- 
Jim Reisert AD1C, , http://www.ad1c.us

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Changing behaviour of pthread_cond_wait().

[Corinna Vinschen]

Hi,

On Mar  7 20:43, Takashi Yano wrote:
> Hello,
> 
> I would like to propose chaging behaviour of pthread_cond_wait().
> 
> POSIX states as follows about pthread_cond_wait():
> If a signal is delivered to a thread waiting for a condition variable,
> upon return from the signal handler the thread resumes waiting for the
> condition variable as if it was not interrupted, or it returns zero
> due to spurious wakeup.
> 
> cygwin 2.7.0 employs the latter behaviour, while Debian GNU/Linux and
> FreeBSD employ the former one. Of course, this is not a cygwin bug.
> However, IMHO, it is better to have the compatibility with the other
> major platforms.
> 
> Because of this difference, iperf 2.0.5 is not terminated normally in
> cygwin 2.7.0. In client mode, iperf 2.0.5 does not stop after measurement
> automatically. It needs ^C to stop it. In server mode, iperf 2.0.5 can
> not stop even by ^C.  Simple test case, attached (pt.c), reproduces this
> problem. I know this test case (and iperf 2.0.5) is essentially unsafe
> because pthread functions are called from signal handler. But, anyway it
> works in Debian GNU/Linux and FreeBSD.
> 
> The test case acts as follows in Debian GNU/Linux and FreeBSD.
> % gcc pt.c -lpthread; ./a.out
> Thread 1
> Alarm 2
> Thread 3
> %
> 
> However, in cygwin, it acs as:
> % gcc pt.c; ./a.exe
> Thread 1
> (Deadlock: ^C is needed to terminate.)
> %
> 
> I would like to propose a patch attached (pthread.patch), for the above
> reason. With this patch, iperf 2.0.5 as well as the test case works fine.

I applied a patch to change the behaviour as proposed, and uploaded
new snapshots to https://cygwin.com/snapshots/ for testing.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygwin console software

[Keith Christian]

Until a few months ago, I used PuttyCyg.  It worked really well, and
still does, and I used it for perhaps 10 years.

In the past few months, I've been using Tera Term, which has a Cygwin
mode that works just like MinTTY and PuttyCyg with the few differences
I've noticed:

1PuttyCyg and other terminals allow copying text by holding
down the SHIFT key and selecting with the left mouse button.  Tera
Term does not.  The workaround is to click File / View Log from the
Tera Term Cygwin terminal window, which loads the scrollback buffer
into an editor, and then cut/paste from there.

The editor to use for (File / View log) is configured in this section
of /cygdrive/c/Program Files (x86)/teraterm/TERATERM.INI file:

; Viewlog Editor path
; ViewlogEditor=C:\Program Files (x86)\Vim\vim74\gvim.exe
ViewlogEditor=C:\Program Files\jEdit\jedit.exe

I settled on Jedit for this.  While Gvim is a great editor, it is not
quite so convenient to copy/paste from as the other Windows editors
(unless you use MSWin mode.)  Notepad, Notepad++, Microsoft Word, or
other text editors work too in the ViewlogEditor field.

2Tera Term Cygwin can log to disk as PuttyCyg and MinTTY do,
but it can add timestamps to the logs, making it easy to see how long
a process runs or a procedure takes.  On *nix there is the "time"
command of course, but, this gives a timeline of a whole session.

3Tera Term Cygwin strips EOL markers from pasted text so if
you're pasting at a prompt, the command won't run away from you until
you press RETURN.  It also pops up a window with the clipboard
contents as a quick verification that you're about to paste what you
THINK you're about to paste.  How many of us have been surprised when
we pasted 10 to 20 lines at the command prompt unexpectedly when we
THOUGHT we'd copied a single word or line?  (Setup / Additional
Settings.)

There are differences in other emulators and Tera Term Cygwin,  but
these are the ones I consider most important, it's been a good
performer for the past few months for me.


Keith

On Sun, Feb 26, 2017 at 11:41 PM, Gary Johnson  wrote:
> On 2017-02-27, Goodman Leung wrote:
>> Hi list
>>
>> Minty is go hard to copy ,
>>
>> Is there any other console software for Cygwin ?
>
> Do you mean that it is hard to copy and paste text to and from
> mintty?  I have no trouble at all using it.  I don't think there is
> anything better--or as good--for Cygwin.
>
> Can you describe the problem you're having in more detail?  Maybe we
> can find a solution.
>
> Regards,
> Gary
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Strange errors running gcc tests on Cygwin

[cyg Simple]

On 3/6/2017 9:03 PM, Daniel Santos wrote:
> On 03/05/2017 05:08 AM, David Billinghurst wrote:
>> No.
>>
>> LD_LIBRARY_PATH is used by dlopen ().
>>
>> PATH is one of the locations searched by Windows when starting
>> applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
> 
> Thank you for this clarification.  So load-time dlls are resolved (in
> ntdll.exe or some such) using PATH and run-time dlls loaded with
> dlopen() are resolved with LD_LIBRARY_PATH?  I'm obviously not intimate
> with Cygwin's architecture, but I'm guessing that explicitly using
> LoadLibrary is still going to use PATH.

You're obviously not intimate with Windows either.  The search algorithm
in Windows is more involved than PATH.  You need to study more.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Changing behaviour of pthread_cond_wait().

[Takashi Yano]

Hello,

I would like to propose chaging behaviour of pthread_cond_wait().

POSIX states as follows about pthread_cond_wait():
If a signal is delivered to a thread waiting for a condition variable,
upon return from the signal handler the thread resumes waiting for the
condition variable as if it was not interrupted, or it returns zero
due to spurious wakeup.

cygwin 2.7.0 employs the latter behaviour, while Debian GNU/Linux and
FreeBSD employ the former one. Of course, this is not a cygwin bug.
However, IMHO, it is better to have the compatibility with the other
major platforms.

Because of this difference, iperf 2.0.5 is not terminated normally in
cygwin 2.7.0. In client mode, iperf 2.0.5 does not stop after measurement
automatically. It needs ^C to stop it. In server mode, iperf 2.0.5 can
not stop even by ^C.  Simple test case, attached (pt.c), reproduces this
problem. I know this test case (and iperf 2.0.5) is essentially unsafe
because pthread functions are called from signal handler. But, anyway it
works in Debian GNU/Linux and FreeBSD.

The test case acts as follows in Debian GNU/Linux and FreeBSD.
% gcc pt.c -lpthread; ./a.out
Thread 1
Alarm 2
Thread 3
%

However, in cygwin, it acs as:
% gcc pt.c; ./a.exe
Thread 1
(Deadlock: ^C is needed to terminate.)
%

I would like to propose a patch attached (pthread.patch), for the above
reason. With this patch, iperf 2.0.5 as well as the test case works fine.

-- 
Takashi Yano 
#include 
#include 
#include 
#include 

pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t c;
int flag = 0;

#define N 2

void sig_handler(int sig)
{
	pthread_mutex_lock(&m);
	flag ++;
	pthread_cond_signal(&c);
	printf("Alarm %d\n", flag); fflush(stdout);
	pthread_mutex_unlock(&m);
}

void *thread_main(void *args)
{
	int i;
	for (i=0; i

pthread.patch
Description: Binary data

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple