Re: GCC-6.4 sys/select.h build failures with std=c++14

2017-09-25 Thread Marco Atzeri 



On 26/09/2017 03:41, Ian Fette wrote:

I tried compiling a very simple program with curl using -std=c++14 under
64-bit cygwin with gcc 6.4.0. When compiling with just g++ main.cpp -lcurl
everything is fine, however if I try to use c++14 as the dialect (g++
main.cpp -lcurl -std=c++14) familiar problems creep up

In file included from /usr/include/curl/curl.h:2547:0,
  from main.cpp:10:
/usr/include/curl/multi.h:155:40: error: ‘fd_set’ has not been declared
 fd_set *read_fd_set,
 ^~
/usr/include/curl/multi.h:156:40: error: ‘fd_set’ has not been declared
 fd_set *write_fd_set,
 ^~
/usr/include/curl/multi.h:157:40: error: ‘fd_set’ has not been declared
 fd_set *exc_fd_set,
 ^~


This is resolved by manually including  before including




this seems more an issue of curl header as from
http://pubs.opengroup.org/onlinepubs/009696899/basedefs/sys/select.h.html

"The  header shall define the fd_set type as a structure."

so if they are using it, they should have a proper include

Marco


--
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: GCC-6.4 sys/select.h build failures with std=c++14

2017-09-25 Thread Brian Inglis 
On 2017-09-25 19:41, Ian Fette wrote:
> I tried compiling a very simple program with curl using -std=c++14 under 
> 64-bit cygwin with gcc 6.4.0. When compiling with just g++ main.cpp -lcurl 
> everything is fine, however if I try to use c++14 as the dialect (g++ 
> main.cpp -lcurl -std=c++14) familiar problems creep up

> This is resolved by manually including  before including 
> 

> This was discussed in the curl project in the past 
> (https://github.com/curl/curl/issues/749) where it was determined that it was
> caused by a cygwin bug which was addressed in 
> https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/types.h;
> h=c9f0fc7f3a9ca420c2372c9af42ce2a0e63e3b1c;hb=ee97c4b22491b205fd3b7697e03c909e02b652d3
> If anyone has thoughts, I'd greatly appreciate it.

A lot of GNU and Cygwin package build problems are avoided by building either
without any -std=... option, or equivalently with -std=gnu++nn, which enables
many non-portable GCC extensions and Unix features, instead of -std=c++nn, which
disables GCC extensions and Unix features, and accepts only portable features
supported by GCC and C++ headers you specify.

In general, try replacing -std=c... with -std=gnu... or omitting -std=... and
see if your program builds without errors or warnings.
Adding -Wall -Wextra will let you know if anything appears questionable to the
compiler.

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

GCC-6.4 sys/select.h build failures with std=c++14

2017-09-25 Thread Ian Fette 
I tried compiling a very simple program with curl using -std=c++14 under
64-bit cygwin with gcc 6.4.0. When compiling with just g++ main.cpp -lcurl
everything is fine, however if I try to use c++14 as the dialect (g++
main.cpp -lcurl -std=c++14) familiar problems creep up

In file included from /usr/include/curl/curl.h:2547:0,
 from main.cpp:10:
/usr/include/curl/multi.h:155:40: error: ‘fd_set’ has not been declared
fd_set *read_fd_set,
^~
/usr/include/curl/multi.h:156:40: error: ‘fd_set’ has not been declared
fd_set *write_fd_set,
^~
/usr/include/curl/multi.h:157:40: error: ‘fd_set’ has not been declared
fd_set *exc_fd_set,
^~


This is resolved by manually including  before including


This was discussed in the curl project in the past (
https://github.com/curl/curl/issues/749) where it was determined that it
was caused by a cygwin bug which was addressed in
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/types.h;h=c9f0fc7f3a9ca420c2372c9af42ce2a0e63e3b1c;hb=ee97c4b22491b205fd3b7697e03c909e02b652d3

If anyone has thoughts, I'd greatly appreciate it. Compiling the following
is sufficient to reproduce.

#include 
#include 

using namespace std;

int main() {

CURL *curl = curl_easy_init();
if(curl) {
  CURLcode res;
  curl_easy_setopt(curl, CURLOPT_URL, "http://example.com;);
  res = curl_easy_perform(curl);
  curl_easy_cleanup(curl);
}

}

--
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: Kindle Fire Utility 0.9.6

2017-09-25 Thread Erik Soderquist 
On Mon, Sep 25, 2017 at 8:14 PM, Kevin McCaffrey wrote:
> Hello,
>
> I am trying to "Install Permanent Root with Superuser" with Kindle Fire


I think you have the wrong list

-- Erik

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

Kindle Fire Utility 0.9.6

2017-09-25 Thread Kevin McCaffrey 
Hello,

 

I am trying to "Install Permanent Root with Superuser" with Kindle Fire
Utility 0.9.6  . I keep getting twrp.img is missing and fff.bin is missing .
Can you tell me how I can install these ? I tried the option "Install latest
FireFireFire" but that also did not work.  The ADB Status shows : Online

and the Boot Status : Unknown . Any help would be appreciated.

 

Thank you,

Kevin

 


--
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: [Attn. Maintainers] Perl 5.26.1-RC1

2017-09-25 Thread Yaakov Selkowitz 
On 2017-09-18 15:00, Ken Brown wrote:
> On 9/18/2017 2:00 PM, Achim Gratz wrote:
>> Ken Brown writes:
 After the install you should be able to create test packages with and
 for the new Perl.
>>>
>>> Thanks.  I've successfully built everything I need.
>>
>> …and that would have been?  Anything that we need to add?
> 
> I built biber, both the current and development versions, and
> perl-PAR-Packer.  (I don't maintain the latter, but I'm probably the
> only person who uses it.  I've been regularly building the current
> version for my own use.)

Would you happen to want it then? :-)

https://github.com/cygwinports/perl-PAR-Packer

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-25 Thread Hans-Bernhard Bröker 

Am 25.09.2017 um 20:44 schrieb Steven Penny:

perhap you are using old versions 


Not exactly.  I'm using the current versions: 2.25.0.1, 5.4.0 
respectively --- you're using not old enough, a.k.a. still "Test"ing 
versions ;-)



--
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] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-25 Thread Steven Penny 

On Mon, 25 Sep 2017 18:43:27, =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= wrote:

> Here is another problem:
> 
> $ cat z.cpp

> #include 
> main() {
>   std::cout << "cout test\n";
> }
> 
> $ x86_64-w64-mingw32-g++ -static -o z z.cpp
> 
> $ ./z

> Segmentation fault

Does not reproduce here.


Scared me for a second - however upon trying this again with a pristine virtual
machine - the error persists

perhap you are using old versions - to repro - you need to be using:

- mingw64-x86_64-binutils 2.28.1
- mingw64-x86_64-gcc-core 6.3.0
- mingw64-x86_64-gcc-g++ 6.3.0


--
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] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-25 Thread Steven Penny 

On Mon, 25 Sep 2017 14:17:28, JonY wrote:

You can actually use Cygwin gdb to debug and see what went wrong,
assuming the debug symbols are around.

Sorry if I'm not much help, kind of busy these days.


New command:

x86_64-w64-mingw32-g++ -g -static -o z z.cpp

Output:

(gdb) run
Starting program: /tmp/z 
[New Thread 5956.0xfe4]

Program received signal SIGSEGV, Segmentation fault.
std::ostream::sentry::sentry (this=this@entry=0x22fd90, __os=...)
 at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
 mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
 ostream.tcc:51
51 /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
 mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
 ostream.tcc: No such file or directory.
(gdb) backtrace
#0  std::ostream::sentry::sentry (this=this@entry=0x22fd90, __os=...)
   at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
   mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
   ostream.tcc:51
#1  0x0049ece9 in std::__ostream_insert
 (__out=..., 
 __s=__s@entry=0x4ab031  "cout test\n", __n=10)

 at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
 mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/bits/
 ostream_insert.h:82
#2  0x004a3547 in std::operator<<  (
 __out=..., __s=0x4ab031  "cout test\n")
 at /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/
 mingw64-x86_64-gcc-6.3.0-1.x86_64/src/gcc-6.3.0/libstdc++-v3/include/std/
 ostream:561
#3  0x004015e0 in main () at z.cpp:3


--
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: Mercurial update needed for security fixes

2017-09-25 Thread Vince Rice 
> On Sep 25, 2017, at 12:31 PM, Andy Moreton  wrote:
> 
> On Mon 18 Sep 2017, Ken Brown wrote:
> 
>> On 9/18/2017 11:27 AM, Andy Moreton wrote:
>>> On Thu 17 Aug 2017, Andy Moreton wrote:
>>> 
>>> Ping?
>>> 
 Hi,
 
 Can the mercurial maintainer please update to upstream Hg 4.3.1, to get
 the fixes for CVE-2017-1000115 and CVE-2017-1000116.
>> 
>> I don't know if he reads the list.  I'm adding him to the Cc.
>> 
>> Ken
> 
> Still no response. If the maintiner does not read the project list or
> respond to email, then all of his packages are effectively abandoned.
> 
> Can we please have a *security update* for mercurial ?

And if "effectively abandoned," then there's no one to update them. Are you 
volunteering?
--
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: Mercurial update needed for security fixes

2017-09-25 Thread Andy Moreton 
On Mon 18 Sep 2017, Ken Brown wrote:

> On 9/18/2017 11:27 AM, Andy Moreton wrote:
>> On Thu 17 Aug 2017, Andy Moreton wrote:
>>
>> Ping?
>>
>>> Hi,
>>>
>>> Can the mercurial maintainer please update to upstream Hg 4.3.1, to get
>>> the fixes for CVE-2017-1000115 and CVE-2017-1000116.
>
> I don't know if he reads the list.  I'm adding him to the Cc.
>
> Ken

Still no response. If the maintiner does not read the project list or
respond to email, then all of his packages are effectively abandoned.

Can we please have a *security update* for mercurial ?

AndyM


--
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] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-25 Thread Hans-Bernhard Bröker 

Am 25.09.2017 um 03:53 schrieb Steven Penny:

On Sun, 24 Sep 2017 00:48:20, JonY wrote:

I don't really work with cmake, but what it looks like, but it probably
makes gcc look in the mingw include dir first and then gcc's, breaking
gcc's headers.


Correct thus far.  -isystem is really not a compiler option that CMake 
should be injecting on its own recognizance.  It's for specs files, 
compiler/libc implementation control and such.  It will almost certainly 
break, among other things, any non-trivial use of #include_next.



Here is another problem:

$ cat z.cpp
#include 
main() {
  std::cout << "cout test\n";
}

$ x86_64-w64-mingw32-g++ -static -o z z.cpp

$ ./z
Segmentation fault


Does not reproduce here.


--
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: chere install problem

2017-09-25 Thread Nellis, Kenneth 
From: Gluszczak, Glenn 
> "Hive not writable" sounds like permission for a registry key.
> Mind you, Cygwin unloads the registry on a filesystem.
> /proc/registry/HKEY_CURRENT_USER/

Thanx for the response. Digging deeper into Google, it turns out that 
I needed to launch mintty "as administrator". Never had to do that in 
Win7. Not sure if this is a Win10 thing or something I can blame on 
our IT department.

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

[ANNOUNCEMENT] c-ares 1.13.0-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libcares2-1.13.0-1
* libcares-devel-1.13.0-1
* mingw64-i686-c-ares-1.13.0-1
* mingw64-x86_64-c-ares-1.13.0-1

c-ares is an asynchronous resolver library.  It is intended for 
applications which need to perform DNS queries without blocking, or need to 
perform multiple DNS queries in parallel.  The primary examples of such 
applications are servers which communicate with multiple clients and 
programs with graphical user interfaces.

This is an update to the latest upstream release:

https://c-ares.haxx.se/changelog.html#1_13_0

--
Yaakov

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

c-ares 1.13.0-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libcares2-1.13.0-1
* libcares-devel-1.13.0-1
* mingw64-i686-c-ares-1.13.0-1
* mingw64-x86_64-c-ares-1.13.0-1

c-ares is an asynchronous resolver library.  It is intended for 
applications which need to perform DNS queries without blocking, or need to 
perform multiple DNS queries in parallel.  The primary examples of such 
applications are servers which communicate with multiple clients and 
programs with graphical user interfaces.

This is an update to the latest upstream release:

https://c-ares.haxx.se/changelog.html#1_13_0

--
Yaakov

[ANNOUNCEMENT] libsndfile 1.0.28-2

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libsndfile1-1.0.28-2
* libsndfile-devel-1.0.28-2
* libsndfile-utils-1.0.28-2
* mingw64-i686-libsndfile-1.0.28-2
* mingw64-x86_64-libsndfile-1.0.28-2

libsndfile is a library of C routines for reading and writing files 
containing sampled audio data.

This release includes a patch for CVE-2017-12562:

https://bugzilla.redhat.com/show_bug.cgi?id=1483140

--
Yaakov

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

libsndfile 1.0.28-2

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libsndfile1-1.0.28-2
* libsndfile-devel-1.0.28-2
* libsndfile-utils-1.0.28-2
* mingw64-i686-libsndfile-1.0.28-2
* mingw64-x86_64-libsndfile-1.0.28-2

libsndfile is a library of C routines for reading and writing files 
containing sampled audio data.

This release includes a patch for CVE-2017-12562:

https://bugzilla.redhat.com/show_bug.cgi?id=1483140

--
Yaakov

[ANNOUNCEMENT] openjpeg2 2.2.0-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* openjpeg2-2.2.0-1
* libopenjp2_7-2.2.0-1
* libopenjp2-devel-2.2.0-1
* libopenjp2-doc-2.2.0-1
* mingw64-i686-openjpeg2-2.2.0-1
* mingw64-x86_64-openjpeg2-2.2.0-1

The OpenJPEG library is an open-source JPEG 2000 codec written in C 
language. It has been developed in order to promote the use of JPEG 2000, 
the new still-image compression standard from the Joint Photographic 
Experts Group (JPEG).

This is an update to the latest upstream release:

http://www.openjpeg.org/2017/08/10/OpenJPEG-2.2.0-released

--
Yaakov

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

openjpeg2 2.2.0-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* openjpeg2-2.2.0-1
* libopenjp2_7-2.2.0-1
* libopenjp2-devel-2.2.0-1
* libopenjp2-doc-2.2.0-1
* mingw64-i686-openjpeg2-2.2.0-1
* mingw64-x86_64-openjpeg2-2.2.0-1

The OpenJPEG library is an open-source JPEG 2000 codec written in C 
language. It has been developed in order to promote the use of JPEG 2000, 
the new still-image compression standard from the Joint Photographic 
Experts Group (JPEG).

This is an update to the latest upstream release:

http://www.openjpeg.org/2017/08/10/OpenJPEG-2.2.0-released

--
Yaakov

[ANNOUNCEMENT] libidn2 2.0.4-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libidn2-2.0.4-1
* libidn2_0-2.0.4-1
* libidn2-devel-2.0.4-1
* libidn2-doc-2.0.4-1
* mingw64-i686-libidn2-2.0.4-1
* mingw64-x86_64-libidn2-2.0.4-1

An implementation of the Stringprep, Punycode and IDNA specifications defined
by the IETF Internationalized Domain Names (IDN) working group.

This is an update to the latest upstream release, which includes security fixes:

https://lists.gnu.org/archive/html/help-libidn/2017-08/msg00015.html

--
Yaakov

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

libidn2 2.0.4-1

2017-09-25 Thread Yaakov Selkowitz 
The following packages have been uploaded to the Cygwin distribution:

* libidn2-2.0.4-1
* libidn2_0-2.0.4-1
* libidn2-devel-2.0.4-1
* libidn2-doc-2.0.4-1
* mingw64-i686-libidn2-2.0.4-1
* mingw64-x86_64-libidn2-2.0.4-1

An implementation of the Stringprep, Punycode and IDNA specifications defined
by the IETF Internationalized Domain Names (IDN) working group.

This is an update to the latest upstream release, which includes security fixes:

https://lists.gnu.org/archive/html/help-libidn/2017-08/msg00015.html

--
Yaakov

RE: chere install problem

2017-09-25 Thread Gluszczak, Glenn 
"Hive not writable" sounds like permission for a registry key.
Mind you, Cygwin unloads the registry on a filesystem.
/proc/registry/HKEY_CURRENT_USER/

--
Moving to a new machine with Windows 10 from an old machine with Windows 7, I 
am installing Cygwin from scratch. I am having trouble with package chere:

$ cygcheck -c chere
Cygwin Package Information
Package  VersionStatus
chere1.4-1  OK
$ chere -if -t mintty -s bash
Error (5): Access is denied.

/usr/bin/chere Error: Hive not writable
/usr/bin/chere: Aborting.
$

I've added "noacl" to the entries in /etc/fstab, but it had no effect:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0 C:/cygwin64/home /home 
dummy binary,noacl

Chere is a marvelously useful utility. I'd hate to have to give it up.
Any help?

--Ken Nellis

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

chere install problem

2017-09-25 Thread Nellis, Kenneth 
Moving to a new machine with Windows 10 from an old machine with Windows 7, 
I am installing Cygwin from scratch. I am having trouble with package chere:

$ cygcheck -c chere
Cygwin Package Information
Package  VersionStatus
chere1.4-1  OK
$ chere -if -t mintty -s bash
Error (5): Access is denied.

/usr/bin/chere Error: Hive not writable
/usr/bin/chere: Aborting.
$

I've added "noacl" to the entries in /etc/fstab, but it had no effect:

none /cygdrive cygdrive binary,noacl,posix=0,user 0 0
C:/cygwin64/home /home dummy binary,noacl

Chere is a marvelously useful utility. I'd hate to have to give it up.
Any help?

--Ken Nellis

--
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] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-25 Thread JonY 
On 09/25/2017 01:53 AM, Steven Penny wrote:
> On Sun, 24 Sep 2017 00:48:20, JonY wrote:
>> I don't really work with cmake, but what it looks like, but it probably
>> makes gcc look in the mingw include dir first and then gcc's, breaking
>> gcc's headers.
>>
>> Unfortunately, I don't have any good ideas besides hacking cmake to
>> remove the -isystem calls, or contacting gcc-help directly.
> 
> Here is another problem:
> 
> $ cat z.cpp
> #include 
> main() {
>  std::cout << "cout test\n";
> }
> 
> $ x86_64-w64-mingw32-g++ -static -o z z.cpp
> 
> $ ./z
> Segmentation fault

You can actually use Cygwin gdb to debug and see what went wrong,
assuming the debug symbols are around.

Sorry if I'm not much help, kind of busy these days.



signature.asc
Description: OpenPGP digital signature

RE: lftp / zlib problems

2017-09-25 Thread Nellis, Kenneth 
From: Harri T.
> Hi all,
> 
> After updating Cygwin 32-bit we have had problems with all the
> combinations of lftp 4.7.7.-1 / 4.8.0-1 and zlib 1.2.8-3 / 1.2.11-1.
> ...
> assertion "ptr(x.heap_index)==" faSKiled: file
> "/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.i686/src/lftp-
> 4.8.0/src/xheap.h", line 127, function: void
> xheap::remove(xheap::node&) [with T = Timer]
> 
> generating a stackdump file.
> 
> Is there something we can do to avoid these issues?

To add some weight to Harri T.'s message, I've reported the same problem twice:

https://sourceware.org/ml/cygwin/2017-08/msg00051.html
https://sourceware.org/ml/cygwin/2017-09/msg00014.html

-Ken Nellis



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

lftp / zlib problems

2017-09-25 Thread Harri T. 
Hi all,

After updating Cygwin 32-bit we have had problems with all the combinations of 
lftp 4.7.7.-1 / 4.8.0-1 and zlib 1.2.8-3 / 1.2.11-1.

1. Command "mget -E myfile*" causes "zlib inflate error: incorrect header 
check" always with Core FTP server 1.2 if there is nothing to retrieve.

lftp myuser@myip:~> set ftp:ssl-allow 0; set ftp:passive-mode 1;
lftp myuser@myip:~> mget -E myfile*;
 Connecting to myip (myip) port 21
<--- 220 Core FTP Server Version 1.2, build 589.2, 64-bit Registered
---> FEAT
<--- 211-Extensions supported
<---   AUTH SSL
<---   MODE Z
<--- 211 END
---> USER myuser
<--- 331 password required for myuser
---> PASS 
<--- 230-Logged on
<--- 230
---> PWD
<--- 257 "/" is current directory
---> MODE Z
<--- 200 Mode set to Z
---> PASV
<--- 227 Entering Passive Mode (...).
 Connecting data socket to (myip) port 52951
 Data connection established
---> LIST
<--- 150 Opening ASCII mode data connection
 Got EOF on data connection
 Closing data socket
<--- 226 Transfer Complete
---> PASV
<--- 227 Entering Passive Mode (...).
 Connecting data socket to (myip) port 52953
 Data connection established
---> NLST
<--- 150 Opening ASCII mode data connection
 zlib inflate error: incorrect header check
 Closing data socket
<--- 226 Transfer Complete
 Closing control socket
mget: myfile*: Fatal error: zlib inflate error: incorrect header check
lftp myuser@myip:~> 

2. Sometimes lftp dies with an error message

---> TYPE I
<--- 200 Switching to Binary mode.
mget: myfile*: no files found
---> QUIT
<--- 221 Goodbye.
 Closing control socket
assertion "ptr(x.heap_index)==" faSKiled: file 
"/home/ASchulma/dev/cygwin/lftp/lftp-4.8.0-1.i686/src/lftp-4.8.0/src/xheap.h", 
line 127, function: void xheap::remove(xheap::node&) [with T = Timer]

generating a stackdump file.

Is there something we can do to avoid these issues?

Br,

Harri



--
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: RPC clnt_create() adress already in use

2017-09-25 Thread PAULUS, Raimund, TI-ABN 
Hallo Mark Geisert,

many thanks for your answer. I supposed this too.

I included in my source code the following function calls after clnt_create():

int fd = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, ); if(bool_ret == true) {
  printf("fd: %d\n", fd);

  int enable = 1;
  retval = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, , sizeof(int));
  if(retval < 0)
fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); }

The function clnt_control() delivers the socket of the RPC-Client-Handle.
The result is the same as before. Moreover i think, the effect of setsockopt() 
would be valid only during the process is running (my test scenarios 1 and 2). 
But it wouldn't change anything regarding my test scenario 3 (several restarts).

Raimund


-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Mark Geisert
Gesendet: Sonntag, 24. September 2017 11:49
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

PAULUS, Raimund, TI-ABN wrote:
> In our environment we have a Linux-Server and several Windows-PCs (Windows XP 
> SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote 
> Procedure Call) are running, one service for one Windows-PC each. To build 
> the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually 
> Cygwin 2.5.1 (because we now have Windows 7 too).
>
> The RPC-Client (*.exe) on the Windows-box is started at any time by hand, 
> establishes a connection to the server (clnt_create), executes a few calls to 
> the server (clnt_call), closes the connection (clnt_destroy) and exits. The 
> time-interval between the program starts can be 10 seconds up to 2 minutes.
>
> This worked over many years without any error (Cygwin 1.5.18).
> Now I upgraded to Cygwin 2_5_1 (libtirpc instead librpc) and there are 
> problems. Sometimes the RPC-Client cannot establish a connection to the 
> server. The error message from clnt_spcreateerror():
>
> Remote system error - Address already in use
>
> I think it is "EADDRINUSE".

I can only answer generally as I haven't tried your testcase and don't know 
anything about either RPC library on Cygwin.  If EADDRINUSE is the error you're 
getting, it might be due to a difference between libtirpc and the older librpc. 
When a program binds a specific address and port to a socket, uses the socket 
then later closes it, the system keeps the  tuple in a "locked" 
state until enough time has passed for the other end of the connection to 
notice the connection's been closed.  During that time, attempting to bind() 
with the same address and port will result in EADDRINUSE.  It's a TCP/IP safety 
mechanism.

If you wish to override that behavior, you set a specific option SO_REUSEADDR 
on the socket with setsockopt() before you issue the bind().  Perhaps libtirpc 
is not doing that, though librpc was doing that.  Only way to know is to 
examine the source to both libraries.  It's possible an strace of a broken 
session compared to an strace of a working session might shed some light.

..mark


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

AW: RPC clnt_create() adress already in use

2017-09-25 Thread PAULUS, Raimund, TI-ABN 


Hallo Mark Geisert,

many thanks for your answer. I supposed this too.

I included in my source code the following function calls after clnt_create():

int fd = 0;
bool bool_ret = clnt_control(cl, CLGET_FD, ); if(bool_ret == true) {
  printf("fd: %d\n", fd);

  int enable = 1;
  retval = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, , sizeof(int));
  if(retval < 0)
fprintf(stderr, "Fehler setsockopt(): %s\n", strerror(errno)); }

The function clnt_control() delivers the socket of the RPC-Client-Handle.
The result is the same as before. Moreover i think, the effect of setsockopt() 
would be valid only during the process is running (my test scenarios 1 and 2). 
But it wouldn't change anything regarding my test scenario 3 (several restarts).

Raimund


-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Mark Geisert
Gesendet: Sonntag, 24. September 2017 11:49
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

PAULUS, Raimund, TI-ABN wrote:
> In our environment we have a Linux-Server and several Windows-PCs (Windows XP 
> SP3, in the past Windows NT too). On the Linux-Server RPC-Services (Remote 
> Procedure Call) are running, one service for one Windows-PC each. To build 
> the RPC-clients on the Windows-boxes, I used Cygwin 1.5.18 and actually 
> Cygwin 2.5.1 (because we now have Windows 7 too).
>
> The RPC-Client (*.exe) on the Windows-box is started at any time by hand, 
> establishes a connection to the server (clnt_create), executes a few calls to 
> the server (clnt_call), closes the connection (clnt_destroy) and exits. The 
> time-interval between the program starts can be 10 seconds up to 2 minutes.
>
> This worked over many years without any error (Cygwin 1.5.18).
> Now I upgraded to Cygwin 2_5_1 (libtirpc instead librpc) and there are 
> problems. Sometimes the RPC-Client cannot establish a connection to the 
> server. The error message from clnt_spcreateerror():
>
> Remote system error - Address already in use
>
> I think it is "EADDRINUSE".

I can only answer generally as I haven't tried your testcase and don't know 
anything about either RPC library on Cygwin.  If EADDRINUSE is the error you're 
getting, it might be due to a difference between libtirpc and the older librpc. 
When a program binds a specific address and port to a socket, uses the socket 
then later closes it, the system keeps the  tuple in a "locked" 
state until enough time has passed for the other end of the connection to 
notice the connection's been closed.  During that time, attempting to bind() 
with the same address and port will result in EADDRINUSE.  It's a TCP/IP safety 
mechanism.

If you wish to override that behavior, you set a specific option SO_REUSEADDR 
on the socket with setsockopt() before you issue the bind().  Perhaps libtirpc 
is not doing that, though librpc was doing that.  Only way to know is to 
examine the source to both libraries.  It's possible an strace of a broken 
session compared to an strace of a working session might shed some light.

..mark


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