Re: cppcheck 1.77 Segmentation fault (64-bit)

2017-01-29 Thread David Stacey 

On 29/01/17 22:13, Christian Franke wrote:

Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.


I could reproduce the cppcheck segfault on 32-bit Cygin if 
libstd++6-6.3.0-1 is installed.


Possibly a variant of this problem:
https://cygwin.com/ml/cygwin/2017-01/msg00315.html


Thank you both for investigating this. At least this isn't something 
that will affect all users. I'm going to be a little busy for a couple 
of days, but I'll take a look at this later in the week.


Dave.


--
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: cppcheck 1.77 Segmentation fault (64-bit)

2017-01-29 Thread Christian Franke 

Jim Reisert AD1C wrote:

Best as I can tell, the seg fault is due to having installed the test
version of gcc 6.0.


I could reproduce the cppcheck segfault on 32-bit Cygin if 
libstd++6-6.3.0-1 is installed.


Possibly a variant of this problem:
https://cygwin.com/ml/cygwin/2017-01/msg00315.html

Downgrading /bin/cygstdc++-6.dll fixes the cppcheck crash.



  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.


Did you possibly miss to downgrade libstdc++6 package ?
It is not visible if 'gcc' is entered in the Search field of setup.exe.

Christian


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

/etc/rebase.db.x86_64 writeable by group None

2017-01-29 Thread Bengt Larsson 
On my system /etc/rebase.db.x86_64 is writable by group None.

--
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: cppcheck 1.77 Segmentation fault (64-bit)

2017-01-29 Thread Jim Reisert AD1C 
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.

- Jim

-- 
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: dirent.d_type is not working on Cygwin symbolic links.

2017-01-29 Thread Thomas Wolff 

Am 29.01.2017 um 20:17 schrieb waterlan:

Christian Franke schreef op 2017-01-29 12:15:

waterlan wrote:
The dirent.d_type value for Cygwin symbolic links is 0 (DT_UNKNOWN). 
The value is 10 (DT_LNK) for Windows native symbolic links. I think 
d_type should be 10 for Cygwin symbolic links too.




Sorry, no.

The actual type should only be returned in dirent.d_type if the info
is available at very low cost. This is not the case for Cygwin
symbolic links.

If DT_UNKNOWN is returned, lstat() must be called if type info is 
required.


Quote from Linux man page readdir(3):
"All applications must properly handle a return of DT_UNKNOWN."
(https://linux.die.net/man/3/readdir)

See also thread starting at:
https://sourceware.org/ml/cygwin-patches/2008-q4/msg0.html


In this case I do not agree with this. Cygwin symbolic links are there 
to emulate Linux symlinks. Therefore I expect the same behaviour.


``Cygwin is
* a large collection of GNU and Open Source tools which provide 
functionality similar to a Linux distribution on Windows.''

(https://cygwin.com/)
As you're quoting from the cygwin home page, you chose the wrong bullet. 
It's about tools while the functionality you are commenting about is 
provided by

* a DLL (cygwin1.dll) which provides substantial POSIX API functionality.
So the reference here is POSIX, not Linux, if we're getting picky. And 
as Christian Franke had already quoted, the field in question is not 
mandatory at all by POSIX. So you'll have to do what other people also 
do: defensive programming, not expecting too much but taking all cases 
into account.

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

Re: dirent.d_type is not working on Cygwin symbolic links.

2017-01-29 Thread waterlan 

Christian Franke schreef op 2017-01-29 12:15:

waterlan wrote:
The dirent.d_type value for Cygwin symbolic links is 0 (DT_UNKNOWN). 
The value is 10 (DT_LNK) for Windows native symbolic links. I think 
d_type should be 10 for Cygwin symbolic links too.




Sorry, no.

The actual type should only be returned in dirent.d_type if the info
is available at very low cost. This is not the case for Cygwin
symbolic links.

If DT_UNKNOWN is returned, lstat() must be called if type info is 
required.


Quote from Linux man page readdir(3):
"All applications must properly handle a return of DT_UNKNOWN."
(https://linux.die.net/man/3/readdir)

See also thread starting at:
https://sourceware.org/ml/cygwin-patches/2008-q4/msg0.html


In this case I do not agree with this. Cygwin symbolic links are there 
to emulate Linux symlinks. Therefore I expect the same behaviour.


``Cygwin is
* a large collection of GNU and Open Source tools which provide 
functionality similar to a Linux distribution on Windows.''

(https://cygwin.com/)

regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

--
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] pcre 8.40-1

2017-01-29 Thread Steven Penny 
On Fri, 27 Jan 2017 15:48:04, Steven Penny wrote:
> Can you update these to include the static library as well? I requested this
> before:

Workaround; static library is available here:

http://repo.msys2.org/mingw/x86_64

Example:

http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-pcre-8.40-1-any.pkg.tar.xz


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

Mosh connection errors

2017-01-29 Thread Roger Qiu 

Hi Everybody,

Upon trying to execute mosh 1.2.5 from the official packages, it gives 
back this:


```

mosh root@host

bash: No such file or directory
write: Broken pipe
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand 
disabled?).


```

No idea what could be causing, but this doesn't happen when I'm on Linux.

Thanks,

Roger

--
https://github.com/CMCDragonkai
+61420925975


--
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: I cannot understand popen/_popen absence

2017-01-29 Thread Hans-Bernhard Bröker 

Am 29.01.2017 um 02:16 schrieb Пётр Б.:

I am trying to build Qt under Cygwin.


What keeps you from using the existing build? Or from at least looking 
at its source package to see how it was managed?


> For some mysterious reason

Cygwin compiler does not expose popen with std=c++11 which is required
for Qt


I rather much doubt that this particular setting is required.  Nor is 
there much mystery about this: std=c++11 is an option that explicitly 
requires the compiler to disable _all_ extensions beyond ISO standard 
C++.  popen is part of the POSIX extensions, so it will be disabled.



BUT
at the same time the MinGW compiler installed from Cygwin repository
does expose popen with same standard flag.


That might be a bug in MinGW, but more likely you overlooked another 
flag that re-enabled some extensions.



--
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: dirent.d_type is not working on Cygwin symbolic links.

2017-01-29 Thread Christian Franke 

waterlan wrote:
The dirent.d_type value for Cygwin symbolic links is 0 (DT_UNKNOWN). 
The value is 10 (DT_LNK) for Windows native symbolic links. I think 
d_type should be 10 for Cygwin symbolic links too.




Sorry, no.

The actual type should only be returned in dirent.d_type if the info is 
available at very low cost. This is not the case for Cygwin symbolic links.


If DT_UNKNOWN is returned, lstat() must be called if type info is required.

Quote from Linux man page readdir(3):
"All applications must properly handle a return of DT_UNKNOWN."
(https://linux.die.net/man/3/readdir)

See also thread starting at:
https://sourceware.org/ml/cygwin-patches/2008-q4/msg0.html

Regards,
Christian


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