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