Re: cppcheck 1.77 Segmentation fault (64-bit)

[David Stacey]

On 29/01/17 21:04, Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.  Even uninstalling gcc 6.0 does not fix the
problem.  I had to create an entirely new Cygwin-64 environment to get
past the problem.

I invite you (Dave) to try the experiment yourself.  You would be wise
to back up your Cygwin environment before doing this.


I've spent a little time looking into this. As per the stack track you 
supplied, cppcheck is falling over constructing a std::istringstream 
with a string passed in to initialise the stream. I'll need to debug 
this into the STL to work out exactly why the seg fault is occurring.


Note that there's more to this than simply constructing a 
std::istringstream - compiling the example given in [1] works fine, even 
if I use the same g++ switches used to build cppcheck. So there's 
something else going on...


Dave.

[1] 
http://www.cplusplus.com/reference/sstream/basic_istringstream/basic_istringstream/



--
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: Issue with delayed process start and effect on Windows 10

[Brian Inglis]

On 2017-02-02 14:12, Paul Kitchen wrote:
> I do indeed have Rapport installed and it looks like it does not co-exist
> well with CYGWIN.
> I rebooted, stopped Rapport and then ran the script I have been trying to
> run for a day and it went through flawlessly at normal speed.
> It is very strange that 2 different applications that have nothing to do
> with each other can interfere with each other in this way.
> Once again thank you for taking the time to respond and also to the CYGWIN
> team for their time and suggestions.

Perhaps you could submit a ticket 
http://www.trusteer.com/en/support/submit-ticket
and inform them that their app does not play well with
https://cygwin.com
hanging unrelated Windows processes for 15-20 seconds, 
and perhaps also copy your bank's security team.

You may also want to search for info about the app and 
consider whether you want to have it running other than 
when you are accessing your bank web site.
It has been reported to interfere with other applications 
and the browsers and may send telemetry to IBM and/or 
your bank: this may be what causes the hangs.
The product privacy link goes nowhere:
http://www.ibm.com/software/products/en/ibm-security-trusteer-rapport-privacy

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Issue with delayed process start and effect on Windows 10

[Brian Inglis]

On 2017-02-02 09:50, Marco Atzeri wrote:
> On 02/02/2017 16:24, Andrey Repin wrote:
>> Greetings, Paul Kitchen!

Could someone please add IBM Trusteer Rapport 
http://www-03.ibm.com/software/products/en/trusteer-rapport
to the BLODA list
https://cygwin.com/faq/faq.html#faq.using.bloda

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Is it OK to mount cygdrive on / ?

[Wells, Roger K.]

On 02/03/2017 04:10 PM, Rustam wrote:

I've added an extra / mountpoint in /etc/fstab in order to be able to
access C: without /cygdrive like this:

none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary,posix=0,user 0 0

It seems to work, I can access the C: drive with just /c.

But normally an "ls /cygdrive" should list the drives, whereas "ls /"
lists the contents of the Cygwin root. So it seems there are now two
root mountpoints overlaying each other.

So I was wondering if my approach is if this is technically undefined
behavior and might conceivably break something or is it OK (less the
drive listing limitation mentioned above).

Thanks,
Rustam


The way that I do it (and have for a long time) is a line in my 
.bash_profile file:

mount --change-cygdrive-prefix /

then ls /c does what you want
but ls / may not

HTH

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





--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com


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

Is it OK to mount cygdrive on / ?

[Rustam]

I've added an extra / mountpoint in /etc/fstab in order to be able to
access C: without /cygdrive like this:

none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary,posix=0,user 0 0

It seems to work, I can access the C: drive with just /c.

But normally an "ls /cygdrive" should list the drives, whereas "ls /"
lists the contents of the Cygwin root. So it seems there are now two
root mountpoints overlaying each other.

So I was wondering if my approach is if this is technically undefined
behavior and might conceivably break something or is it OK (less the
drive listing limitation mentioned above).

Thanks,
Rustam

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

[newlib-cygwin] Fix limited Internet speeds caused by inappropriate socket buffering

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=609d2b22afc63d80029a4fe85e64b51c84ccae08

commit 609d2b22afc63d80029a4fe85e64b51c84ccae08
Author: Corinna Vinschen 
Date:   Fri Feb 3 21:46:01 2017 +0100

Fix limited Internet speeds caused by inappropriate socket buffering

Don't set SO_RCVBUF/SO_SNDBUF to fixed values, thus disabling autotuning.

Patch modeled after a patch suggestion from Daniel Havey 
in https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html:

At Windows we love what you are doing with Cygwin.  However, we have
been getting reports from our hardware vendors that iperf is slow on
Windows.  Iperf is of course compiled against the cygwin1.dll and we
believe we have traced the problem down to the function fdsock in
net.cc.  SO_RCVBUF and SO_SNDBUF are being manually set.  The comments
indicate that the idea was to increase the buffer size, but, this code
must have been written long ago because Windows has used autotuning
for a very long time now.  Please do not manually set SO_RCVBUF or
SO_SNDBUF as this will limit your internet speed.

I am providing a patch, an STC and my cygcheck -svr output.  Hope we
can fix this.  Please let me know if I can help further.

Simple Test Case:
I have a script that pings 4 times and then iperfs for 10 seconds to
debit.k-net.fr

With patch
$ bash buffer_test.sh 178.250.209.22
usage: bash buffer_test.sh 

Pinging 178.250.209.22 with 32 bytes of data:
Reply from 178.250.209.22: bytes=32 time=167ms TTL=34
Reply from 178.250.209.22: bytes=32 time=173ms TTL=34
Reply from 178.250.209.22: bytes=32 time=173ms TTL=34
Reply from 178.250.209.22: bytes=32 time=169ms TTL=34

Ping statistics for 178.250.209.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 167ms, Maximum = 173ms, Average = 170ms

Client connecting to 178.250.209.22, TCP port 5001
TCP window size: 64.0 KByte (default)

[  3] local 10.137.196.108 port 58512 connected with 178.250.209.22 port 
5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 1.0 sec   768 KBytes  6.29 Mbits/sec
[  3]  1.0- 2.0 sec  9.25 MBytes  77.6 Mbits/sec
[  3]  2.0- 3.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  3.0- 4.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  4.0- 5.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  5.0- 6.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  6.0- 7.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  7.0- 8.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  8.0- 9.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  9.0-10.0 sec  18.0 MBytes   151 Mbits/sec
[  3]  0.0-10.0 sec   154 MBytes   129 Mbits/sec

Without patch:
dahavey@DMH-DESKTOP ~
$ bash buffer_test.sh 178.250.209.22

Pinging 178.250.209.22 with 32 bytes of data:
Reply from 178.250.209.22: bytes=32 time=168ms TTL=34
Reply from 178.250.209.22: bytes=32 time=167ms TTL=34
Reply from 178.250.209.22: bytes=32 time=170ms TTL=34
Reply from 178.250.209.22: bytes=32 time=169ms TTL=34

Ping statistics for 178.250.209.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 167ms, Maximum = 170ms, Average = 168ms

Client connecting to 178.250.209.22, TCP port 5001
TCP window size:  208 KByte (default)

[  3] local 10.137.196.108 port 58443 connected with 178.250.209.22 port 
5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 1.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  1.0- 2.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  2.0- 3.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  3.0- 4.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  4.0- 5.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  5.0- 6.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  6.0- 7.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  7.0- 8.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  8.0- 9.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  9.0-10.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3]  0.0-10.1 sec  14.1 MBytes  11.7 Mbits/sec

The output shows that the RTT from my machine to the iperf server is
similar in both cases (about 170ms) however with the patch the
throughput averages 129 Mbps while without the patch the throughput
only averages 11.7 Mbps.  If we calculate the maximum throughput using
Bandwidth = Queue/RTT we get (212992 * 8)/0.170 = 10.0231 Mbps.  This
is just about what iperf is showing us without the patch since the
buffer size is set to 212992 I believe that 

[newlib-cygwin] Add release message for commit 609d2b2

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a9f4b71e8e63c363cd461aec3e0910dfd492e777

commit a9f4b71e8e63c363cd461aec3e0910dfd492e777
Author: Corinna Vinschen 
Date:   Fri Feb 3 21:54:25 2017 +0100

Add release message for commit 609d2b2

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.7.0 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/winsup/cygwin/release/2.7.0 b/winsup/cygwin/release/2.7.0
index 37ef3c7..9ed0a00 100644
--- a/winsup/cygwin/release/2.7.0
+++ b/winsup/cygwin/release/2.7.0
@@ -28,3 +28,6 @@ Bug Fixes
 
 - Fix handling of a literal '+' by cygcheck -p
   Addresses:  https://cygwin.com/ml/cygwin/2014-01/msg00287.html
+
+- Fix limited Internet speeds caused by inappropriate socket buffering.
+  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html

Updated [test]: coreutils-8.26-2

[Eric Blake (cygwin)]

A new release of coreutils, 8.26-2, has been uploaded, and will be
available soon from your favorite mirror.  The new release is
experimental, and REQUIRES the use of the experimental cygwin-2.7.0-0.1
(or better) release; the current version remains 8.26-1 for
compatibility with the current stable cygwin dll; once the next cygwin
release occurs, I will promote 8.26-2 to current with another
announcement email.

NEWS:
=
This is a minor rebuild to add 'stty -iutf8' functionality, now that the
experimental cygwin has added this terminal knob.  For upstream details,
see /usr/share/doc/coreutils/NEWS.

If you encounter a regression, please report it here rather than
upstream.  See also the upstream documentation in /usr/share/doc/coreutils/.

DESCRIPTION:

GNU coreutils provides a collection of commonly used utilities essential
to a standard POSIX environment.  It comprises the former textutils,
sh-utils, and fileutils packages.  The following executables are included:

[ arch b2sum base32 base64 basename cat chcon chgrp chmod chown chroot
cksum comm cp csplit cut date dd df dir dircolors dirname du echo env
expand expr factor false fmt fold gkill groups head hostid id install
join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd
readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum
sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum
sync tac tail tee test timeout touch tr true truncate tsort tty uname
unexpand uniq unlink users vdir wc who whoami yes

UPDATE:
===
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. Save it and run setup, answer the questions and pick up
'coreutils' from the 'Base' category.

DOWNLOAD:
=
Note that downloads from cygwin.com aren't allowed due to bandwidth
limitations.  This means that you will need to find a mirror which has
this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin coreutils package maintainer

For more details on this list (including unsubscription), see:
http://sourceware.org/lists.html

[ANNOUNCEMENT] Updated [test]: coreutils-8.26-2

[Eric Blake (cygwin)]

A new release of coreutils, 8.26-2, has been uploaded, and will be
available soon from your favorite mirror.  The new release is
experimental, and REQUIRES the use of the experimental cygwin-2.7.0-0.1
(or better) release; the current version remains 8.26-1 for
compatibility with the current stable cygwin dll; once the next cygwin
release occurs, I will promote 8.26-2 to current with another
announcement email.

NEWS:
=
This is a minor rebuild to add 'stty -iutf8' functionality, now that the
experimental cygwin has added this terminal knob.  For upstream details,
see /usr/share/doc/coreutils/NEWS.

If you encounter a regression, please report it here rather than
upstream.  See also the upstream documentation in /usr/share/doc/coreutils/.

DESCRIPTION:

GNU coreutils provides a collection of commonly used utilities essential
to a standard POSIX environment.  It comprises the former textutils,
sh-utils, and fileutils packages.  The following executables are included:

[ arch b2sum base32 base64 basename cat chcon chgrp chmod chown chroot
cksum comm cp csplit cut date dd df dir dircolors dirname du echo env
expand expr factor false fmt fold gkill groups head hostid id install
join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl
nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd
readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum
sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum
sync tac tail tee test timeout touch tr true truncate tsort tty uname
unexpand uniq unlink users vdir wc who whoami yes

UPDATE:
===
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. Save it and run setup, answer the questions and pick up
'coreutils' from the 'Base' category.

DOWNLOAD:
=
Note that downloads from cygwin.com aren't allowed due to bandwidth
limitations.  This means that you will need to find a mirror which has
this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin coreutils package maintainer

For more details on this list (including unsubscription), see:
http://sourceware.org/lists.html

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

[ANNOUNCEMENT] Updated: fftw3-3.3.6-pl1-1

[Marco Atzeri]

Versions 3.3.6-pl1-1 of
  fftw3
  fftw3-doc
  libfftw3-devel
  libfftw3_3
  libfftw3-omp3

have been uploaded for cygwin.

CHANGES
Latest upstream release.
Full info:
http://www.fftw.org/release-notes.html

DESCRIPTION
FFTW is a C subroutine library for computing the discrete
Fourier transform (DFT) in one or more dimensions.

HOMEPAGE
http://www.fftw.org/

Regards
Marco Atzeri


If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

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

[ANNOUNCEMENT] Updated: R-3.3.2-1

[Marco Atzeri]

Versions 3.3.2-1  of
R
libRmath
libRmath-devel

for cygwin are now available:

CHANGES
New upstream release
https://mailman.stat.ethz.ch/pipermail/r-announce/2016/000608.html

CYGWIN CHANGES
As upstream removed most of cygwin specific code, the package is
now linked to the lapack library and not using anymore the internal
library.

DESCRIPTION
R is a language and environment for statistical computing and graphics.

R provides a wide variety of statistical (linear and nonlinear
modelling, classical statistical tests, time-series analysis,
classification, clustering, ...) and graphical techniques, and
is highly extensible.
The S language is often the vehicle of choice for research in
statistical methodology, and R provides an Open Source route
to participation in that activity.

HOMEPAGE
http://www.r-project.org/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

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

Updated: fftw3-3.3.6-pl1-1

[Marco Atzeri]

Versions 3.3.6-pl1-1 of
  fftw3
  fftw3-doc
  libfftw3-devel
  libfftw3_3
  libfftw3-omp3

have been uploaded for cygwin.

CHANGES
Latest upstream release.
Full info:
http://www.fftw.org/release-notes.html

DESCRIPTION
FFTW is a C subroutine library for computing the discrete
Fourier transform (DFT) in one or more dimensions.

HOMEPAGE
http://www.fftw.org/

Regards
Marco Atzeri


If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

Updated: R-3.3.2-1

[Marco Atzeri]

Versions 3.3.2-1  of
R
libRmath
libRmath-devel

for cygwin are now available:

CHANGES
New upstream release
https://mailman.stat.ethz.ch/pipermail/r-announce/2016/000608.html

CYGWIN CHANGES
As upstream removed most of cygwin specific code, the package is
now linked to the lapack library and not using anymore the internal
library.

DESCRIPTION
R is a language and environment for statistical computing and graphics.

R provides a wide variety of statistical (linear and nonlinear
modelling, classical statistical tests, time-series analysis,
classification, clustering, ...) and graphical techniques, and
is highly extensible.
The S language is often the vehicle of choice for research in
statistical methodology, and R provides an Open Source route
to participation in that activity.

HOMEPAGE
http://www.r-project.org/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

Re: Providing cygwin1.dll in both 32- and 64-bit versions

[Hans-Bernhard Bröker]

Am 03.02.2017 um 12:49 schrieb Thomas Nilefalk:

Hans-Bernhard Bröker skrev:

Am 02.02.2017 um 22:12 schrieb Thomas Nilefalk:



'how can I make a 32-bit compiled cygwin program run under cygwin64'?


You can't. Nor can anybody else.  For a Cygwin64-based program,
Cygwin32 is a bona fide cross-compilation platform rather than just
some subset of the same platform.  The same holds vice versa.



What triggered this chain of thought was that running an exe
cross-compiled to 32-bit just silently failed.


BTDT, and can feel your pain.


It would have helped me at that time if I would have gotten an error
message from the dynamic loader, like on other platforms ("skipping
cygwin1.dll because it has the wrong architecture").


Welcome to one of the deeper levels of the tragedy (or comedy of 
errors...) commonly known as Windows "DLL hell".  AFAIK there is no 
dynamic loader Cygwin would have any amount of control over.  This fails 
before any part of Cygwin ever gets loaded, so there's practically 
nothing cygwin can do about it.



Anyways, thanks for the explanation. Given that, the solution for runnig
32-bit cygwin programs on cygwin64 is of course

$ PATH=:$PATH
<32-bit_cross_compiled_program>


Actually that's not the solution, either.  It's an unreliable workaround 
at best.  That's because after this, all 64-bit cygwin programs executed 
by your own program will fail to start because they get the wrong Cygwin 
DLL.


The solution is to have a Cygwin32 environment installed independently 
of Cygwin64, and keep each executable strictly in its own environment. 
Mixing the two causes nothing but problems.


--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Houder]

On Fri, 03 Feb 2017 04:48:49, Steven Penny wrote:
> On Fri, 03 Feb 2017 10:30:23, Houder wrote:
> > Apologies for the confusion ... the unicode symbol I was pasting in was
> > the latin small letter o with diaeresis ...
> > For some reason something went wrong when I composed my e-mail.
> 
> I had the same problem. You need to add
> 
> Content-Type: text; charset=UTF-8
> 
> http://github.com/svnpenn/a/blob/d7afee6/etc/mailing-list.awk#L45
> 
> If you leave this off, if defaults to US-ASCII:
> 
> http://tools.ietf.org/html/rfc2046#section-4.1.2

Ah! Of course. I missed that! Thank you.

Regards,

Henri

=


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

[ANNOUNCEMENT] Updated: slrn-1.0.3a-1

[Marco Atzeri]

New version 1.0.3a-1 has been uploaded.

CHANGES
  This is a upstream bgfix release.
  full list of changes
  http://slrn.sourceforge.net/docs/changes.txt

DESCRIPTION
slrn ('S-Lang read news') is a newsreader, i.e. a program that accesses
a newsserver to read messages from the Internet News service (also
known as 'Usenet'). It runs in console mode. Beside the usual features
of a newsreader slrn supports scoring rules to highlight, sort or kill
articles based on information from their header. It is highly customizable,
allows free key-bindings and can easily be extended using the sophisticated
S-Lang macro language. Offline reading is possible by using either
slrnpull (shipped with slrn) or a local newsserver (like leafnode or INN).

HOMEPAGE
http://www.slrn.org/

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

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

[ANNOUNCEMENT] Updated: S-Lang 2.3.1a-1

[Marco Atzeri]

New versions 2.3.1a-1 of

  libslang2
  libslang-devel
  slsh

are available in the Cygwin distribution

DESCRIPTION
S-Lang is a multi-platform programmer's library designed
to allow a developer to create robust multi-platform software.
It provides facilities required by interactive applications
such as display/screen management, keyboard input, keymaps, and so on


CHANGES
Update to  last upstream main release.
Full details on:
http://lists.jedsoft.org/lists/slang-users/2016/014.html

HOMEPAGE
http://http://www.jedsoft.org/slang/
(mirrored at http://www.s-lang.org/ )

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

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

Updated: S-Lang 2.3.1a-1

[Marco Atzeri]

New versions 2.3.1a-1 of

  libslang2
  libslang-devel
  slsh

are available in the Cygwin distribution

DESCRIPTION
S-Lang is a multi-platform programmer's library designed
to allow a developer to create robust multi-platform software.
It provides facilities required by interactive applications
such as display/screen management, keyboard input, keymaps, and so on


CHANGES
Update to  last upstream main release.
Full details on:
http://lists.jedsoft.org/lists/slang-users/2016/014.html

HOMEPAGE
http://http://www.jedsoft.org/slang/
(mirrored at http://www.s-lang.org/ )

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

Updated: slrn-1.0.3a-1

[Marco Atzeri]

New version 1.0.3a-1 has been uploaded.

CHANGES
  This is a upstream bgfix release.
  full list of changes
  http://slrn.sourceforge.net/docs/changes.txt

DESCRIPTION
slrn ('S-Lang read news') is a newsreader, i.e. a program that accesses
a newsserver to read messages from the Internet News service (also
known as 'Usenet'). It runs in console mode. Beside the usual features
of a newsreader slrn supports scoring rules to highlight, sort or kill
articles based on information from their header. It is highly customizable,
allows free key-bindings and can easily be extended using the sophisticated
S-Lang macro language. Offline reading is possible by using either
slrnpull (shipped with slrn) or a local newsserver (like leafnode or INN).

HOMEPAGE
http://www.slrn.org/

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Steven Penny]

On Fri, 03 Feb 2017 10:30:23, Houder wrote:
> Apologies for the confusion ... the unicode symbol I was pasting in was
> the latin small letter o with diaeresis ...
> For some reason something went wrong when I composed my e-mail.

I had the same problem. You need to add

Content-Type: text; charset=UTF-8

http://github.com/svnpenn/a/blob/d7afee6/etc/mailing-list.awk#L45

If you leave this off, if defaults to US-ASCII:

http://tools.ietf.org/html/rfc2046#section-4.1.2

which is insane because US-ASCII only supports 128 characters:

http://wikipedia.org/wiki/ASCII#Overview


--
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: Providing cygwin1.dll in both 32- and 64-bit versions

[Thomas Nilefalk]

Hans-Bernhard Bröker skrev:

Am 02.02.2017 um 22:12 schrieb Thomas Nilefalk:


Using 'i686-pc-cygwin-gcc' creates an executable but that is un-runnable
in a Cygwin64 environment because the cygwin1.dll is a 64-bit version
and not compatible with the produced executable. A cygwin32 DLL needs to
be put first in the path to make the executable run.

Is this by design?


Pretty much, yes.  Windows itself already has a seriously hard time 
mixing and matching 32-bit and 64-bit executables and their DLLs.  The 
tricks MS uses to pull that off range from outright scary to 
Marx-Brothers-grade hilarious, depending how you look at them.


As I see it, Cygwin rightfully opted for sanity here by keeping the 
two worlds separate.

I'm quite ok with this.




At least it seems to me that 'gcc -m32' could be
taken to mean 'create an executable in the current ABI-environment
(cygwin64) which uses a 32-bit architecture'.


No, it really can't.  -m32 does what the GCC documentation says: it 
makes GCC generate 32-bit x86 code.  Nothing in there so much as 
suggests that such code will actually work in a given ABI environment. 
In the case of Cygwin64 it won't.



Fair enough.


'how can I make a 32-bit compiled cygwin program run under cygwin64'?


You can't. Nor can anybody else.  For a Cygwin64-based program, 
Cygwin32 is a bona fide cross-compilation platform rather than just 
some subset of the same platform.  The same holds vice versa.
What triggered this chain of thought was that running an exe 
cross-compiled to 32-bit just silently failed. When I straced it I got 
the Windows prompt saying "could not start 0xc07b" (or something 
similar). It took me a while to figure out what was wrong, which 
obviously was that the cygwin1.dll was 64-bit.


It would have helped me at that time if I would have gotten an error 
message from the dynamic loader, like on other platforms ("skipping 
cygwin1.dll because it has the wrong architecture"). I'm not readup on 
cygwin internals enough to understand if this is even possible or if the 
dynamic loader is just the standard Windows one. If it's the standard 
Windows one, we could either hope for a Microsoft action here, or 
wait/suggest/implement some special things in the startup code that did 
this.


Anyways, thanks for the explanation. Given that, the solution for runnig 
32-bit cygwin programs on cygwin64 is of course


$ PATH=:$PATH 
<32-bit_cross_compiled_program>


/Thomas



--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Houder]

On Fri, 03 Feb 2017 10:09:51, Houder wrote:
> On Fri, 3 Feb 2017 09:39:47, Corinna Vinschen wrote:
> 
> > Cygwin 2.7.0:
> > 
> > Works in tcsh and dash, even with chcp 65001.  Does not work with
> > bash for some reason in cp 65001.
> 
> Using the Windows Console:
> 
> 64 LANG = en_US.UTF-8, LC_ALL =
> => LANG = en_US.UTF-8
> 64-@@ cygcheck -sv | awk '$1 ~ /^(libreadline.|cygwin|"cygwin1.dll")$/'
>   "cygwin1.dll" v0.0 ts=2017-01-31 15:28
> cygwin  2.7.0-0.1OK
> libreadline77.0.1-1  OK
> 
> 64-@@ chcp.com < changed from 437 to 65001 for testing only
> Active code page: 65001
> 
> 64-@@ % < canNOT paste ö (if libreadline is enabled)
> bash: fg: %: no such job
> 
> 64-@@ bash --noediting < switch off libreadline
> => LANG = en_US.UTF-8
> 64-@@ %ö < I can paste ö when libreadline has been switched off
> bash: fg: %ö: no such job

Apologies for the confusion ... the unicode symbol I was pasting in was
the latin small letter o with diaeresis ...

For some reason something went wrong when I composed my e-mail.

=


--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Corinna Vinschen]

On Feb  3 09:39, Corinna Vinschen wrote:
> On Feb  2 17:50, Steven Penny wrote:
> > On Thu, 02 Feb 2017 17:37:35, Steven Penny wrote:
> > > Ok, I found that if I install cygwin-2.7.0 and libreadline7-7.0.1-2 then 
> > > this
> > > works as exepcted. I didnt realize libreadline7-7.0.1-2 was still in test
> > > status. However I thought that the Cygwin DLL update meant that the 
> > > readline
> > > hack was not necessary? Please advise.
> > 
> > Correction again, this nightmare keeps getting worse. Using this test:
> > 
> > %ö
> > 
> > Pasting fails for every recent combination. The only fix I found was falling
> > back to bash-4.3.48 and libreadline7-6.3.8. Please fix this, starting to 
> > make my
> > head hurt.
> 
> Cygwin 2.7.0:
> 
> Works in tcsh and dash, even with chcp 65001.  Does not work with
> bash for some reason in cp 65001.
> 
> Why are you switching to cp 65001, btw?  It's completely unnecessary
> for utf-8 to work in the Windows console.  Just stick to the default.

I wonder if that's a problem in the Windows console.  In theory the
console codepage should have no influence on Cygwin.  Codepages only
should influence non-Unicode aware applications, but console I/O in
Cygwin is using Unicode throughout.

Weird.


Corinna

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


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Houder]

On Fri, 3 Feb 2017 09:39:47, Corinna Vinschen wrote:

> Cygwin 2.7.0:
> 
> Works in tcsh and dash, even with chcp 65001.  Does not work with
> bash for some reason in cp 65001.

Using the Windows Console:

64 LANG = en_US.UTF-8, LC_ALL =
=> LANG = en_US.UTF-8
64-@@ cygcheck -sv | awk '$1 ~ /^(libreadline.|cygwin|"cygwin1.dll")$/'
  "cygwin1.dll" v0.0 ts=2017-01-31 15:28
cygwin  2.7.0-0.1OK
libreadline77.0.1-1  OK

64-@@ chcp.com < changed from 437 to 65001 for testing only
Active code page: 65001

64-@@ % < canNOT paste ö (if libreadline is enabled)
bash: fg: %: no such job

64-@@ bash --noediting < switch off libreadline
=> LANG = en_US.UTF-8
64-@@ %ö < I can paste ö when libreadline has been switched off
bash: fg: %ö: no such job

libreadline must be the culprit ...

Regards,

Henri

=


--
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.7.0-0.1

[Corinna Vinschen]

On Feb  2 17:50, Steven Penny wrote:
> On Thu, 02 Feb 2017 17:37:35, Steven Penny wrote:
> > Ok, I found that if I install cygwin-2.7.0 and libreadline7-7.0.1-2 then 
> > this
> > works as exepcted. I didnt realize libreadline7-7.0.1-2 was still in test
> > status. However I thought that the Cygwin DLL update meant that the readline
> > hack was not necessary? Please advise.
> 
> Correction again, this nightmare keeps getting worse. Using this test:
> 
> %ö
> 
> Pasting fails for every recent combination. The only fix I found was falling
> back to bash-4.3.48 and libreadline7-6.3.8. Please fix this, starting to make 
> my
> head hurt.

Cygwin 2.7.0:

Works in tcsh and dash, even with chcp 65001.  Does not work with
bash for some reason in cp 65001.

Why are you switching to cp 65001, btw?  It's completely unnecessary
for utf-8 to work in the Windows console.  Just stick to the default.


Corinna

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


signature.asc
Description: PGP signature