Re: cygwin 2.4.1: broken ps_AF and ps_AF.utf8 locales

[Tony Cook]

Achim Gratz said:
> You've been digging at the Perl locale test fails?

More that Karl Williamson was, I just turned it into a report.

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: Defining _GNU_SOURCE hides the declaration of aligned_alloc

[Ken Brown]

On 2/2/2016 5:27 PM, Ken Brown wrote:

The issue in the Subject line came up in connection with an emacs bug
report.

Here's a test case:

$ cat test.c
#define _GNU_SOURCE
#include 

int
main ()
{
   aligned_alloc (1, 1);
}

$ gcc test.c -Wimplicit-function-declaration
test.c: In function ‘main’:
test.c:7:3: warning: implicit declaration of function ‘aligned_alloc’

The cause is that the declaration of aligned_alloc in stdlib.h is
guarded by #if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L; but
defining _GNU_SOURCE causes __ISO_C_VISIBLE to be defined as 1999.
Here's an excerpt from /usr/include/sys/cdefs.h showing how this happens:

/* Deal with _GNU_SOURCE, which implies everything and the kitchen sink */
#ifdef _GNU_SOURCE
[...]
#define_XOPEN_SOURCE700
[...]
#endif
[...]
#if _XOPEN_SOURCE - 0 >= 700
[...]
#define_POSIX_C_SOURCE200809
[...]
#endif
[...]
#if _POSIX_C_SOURCE >= 200809
[...]
#define__ISO_C_VISIBLE1999
[...]
#endif /* _POSIX_C_SOURCE */

According to the discussion of the emacs bug I mentioned, Linux and
FreeBSD don't have this issue.  Should Cygwin's headers be changed to
conform to those other platforms?


Paul Eggert says they should:


Defining _GNU_SOURCE should make aligned_alloc visible regardless of whether -std=c99 is 
specified. This is because defining _GNU_SOURCE means, "Make GNU symbols visible 
even when compiling pedantically." This is OK, since the C standard says the 
behavior is undefined whenever the user defines a reserved symbol like _GNU_SOURCE.


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

Defining _GNU_SOURCE hides the declaration of aligned_alloc

[Ken Brown]

The issue in the Subject line came up in connection with an emacs bug 
report.


Here's a test case:

$ cat test.c
#define _GNU_SOURCE
#include 

int
main ()
{
  aligned_alloc (1, 1);
}

$ gcc test.c -Wimplicit-function-declaration
test.c: In function ‘main’:
test.c:7:3: warning: implicit declaration of function ‘aligned_alloc’

The cause is that the declaration of aligned_alloc in stdlib.h is 
guarded by #if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L; but 
defining _GNU_SOURCE causes __ISO_C_VISIBLE to be defined as 1999. 
Here's an excerpt from /usr/include/sys/cdefs.h showing how this happens:


/* Deal with _GNU_SOURCE, which implies everything and the kitchen sink */
#ifdef _GNU_SOURCE
[...]
#define_XOPEN_SOURCE700
[...]
#endif
[...]
#if _XOPEN_SOURCE - 0 >= 700
[...]
#define_POSIX_C_SOURCE200809
[...]
#endif
[...]
#if _POSIX_C_SOURCE >= 200809
[...]
#define__ISO_C_VISIBLE1999
[...]
#endif /* _POSIX_C_SOURCE */

According to the discussion of the emacs bug I mentioned, Linux and 
FreeBSD don't have this issue.  Should Cygwin's headers be changed to 
conform to those other platforms?


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

Re: less.exe v481-1 cannot seek to EOF in CRLF file; current cygwin32, Win10 only.

[KARL BOTTS]

This is to close out my earlier bug report.  I think it contains a useful
caveat for others.

I have a very old cygwin installation, which I propagate by updating it on one
machine via setup.exe, and then copying the whole c:/cygwin tree to several
other machines, with tar or rsync.  I have not installed it from scratch for
well over ten years.  After I updated from cyg1.7 to cyg2.3, I started having
various line-ending related problems, particularly from  and .

I reported that here under the subject line of this message, a week or so ago.
 Helmut and Marco kindly tried to reproduce it, and failed.  I inferred from
this that there was something wrong with my ancient installation.  I
reinstalled from scratch on one machine, and the problems were gone.  After
diffing and digging for awhile, I think I found the problem:

My old /etc/fstab, that had not been changed for years and worked under 1.7,
has one non-comment line:

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

The same file in the from-scratch install (after running 'mount -c /') has:

none / cygdrive binary,user 0 0

Also present in my (even more ancient) home dir, is a bash script containing
lines like:

mount -u -t --change-cygdrive-prefix "/"
mount -s -t --change-cygdrive-prefix "/"

Note that the -u, -s and -t options are not supported by cygwin 
anymore.  I dimly remember that, long ago, I would run that script after
copying to a new machine, but I have not done so for years.

So the upshot, I think, is this:

Cygwin _used_ to support the notion of mounting volumes with a "text" option,
which had some effect on how line endings were handled.  I am not sure it was
ever valuable, and I don't remember why I did it, but apparently I did, long
ago.

Cygwin no longer really supports the "text" option (you could still set it
with mount -o, but I do not recommend that).  Further, it is no longer needed,
if it ever was, which I doubt.  And with it, some critical apps will suffer
line ending problems.  So don't do that.

I think the Win10 business was a red herring.

Thanks for everyone's help and patience.

---
Karl Botts, kdbo...@usa.net



--
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: Compiling gcc trunk under cygwin

[Roger Orr]

FYI
Fixes for both issues now released to gcc trunk.
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 27 January 2016 00:16
To: 'cygwin@cygwin.com'
Subject: RE: Compiling gcc trunk under cygwin

FYI
(1) Revision 232071 problem

The pr66655 has a new proposed patch, which does appear to build on cygwin,
and is awaiting final approval.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

(2) Revision 232454 problem

I've now reported the revision 232454 problem as pr69506 (as it's been well
over a week since the problematic check-in)

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506

Regards,
Roger.

-Original Message-
From: Roger Orr [mailto:rog...@howzatt.demon.co.uk] 
Sent: 23 January 2016 14:19
To: cygwin@cygwin.com
Subject: Re: Compiling gcc trunk under cygwin

David Wohlferd  LimeGreenSocks.com> writes:

> Until recently, I've been able to build gcc under cygwin just fine. But 
> (relatively) recent checkins (232454 &  232071) are causing problems.

Have you reported the problems with 232454 to gcc yet?

I've already reported the 232071 problem, on the original bug report this
was trying to fix. See gcc's bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
 
Roger.



--
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: cygwin 2.4.1: broken ps_AF and ps_AF.utf8 locales

[Achim Gratz]

Tony Cook  develop-help.com> writes:
> Simplified to a C program below, calls to sprintf() under the ps_AF
> and ps_AF.utf8 locales are returning a value that doesn't match the
> length of the formatted string:

You've been digging at the Perl locale test fails?
:-)


Regards,
Achim.



--
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: Fork and crashing problems

[James Darnley]

On 2016-02-02 15:53, Achim Gratz wrote:
> James Darnley  gmail.com> writes:
>>> 0 [main] sh 10684 fork: child -1 - forked process 7812 died
> unexpectedly, retry 0, exit code 0xC005,
>> errno 11
> 
> Well, that exit code is ACCESS_VIOLATION... if you are sure it's not BLODA
> related and it fails only intermittently and always with a different
> program, I'd run a memory test.

Do you mean something like Memtest86?




signature.asc
Description: OpenPGP digital signature

Re: Fork and crashing problems

[Achim Gratz]

James Darnley  gmail.com> writes:
> > Well, that exit code is ACCESS_VIOLATION... if you are sure it's not BLODA
> > related and it fails only intermittently and always with a different
> > program, I'd run a memory test.
> 
> Do you mean something like Memtest86?

Yes, or maybe your BIOS has a built-in memory check, but these tend to be
not as thorough.  You might also want to check if your graphics drivers are
up-to-date, they've been blamed for causing trouble like this in other
instances, especially if the screensaver kicks in during high load.  But I'd
rule out dodgy memory first, let it run for at least four full test cycles
(that should take quite a while depending on how much memory you have).


Regards,
Achim.


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

Fork and crashing problems

[James Darnley]

Hello.

I know that fork issues are usually related to the BLODA programs.  I
don't think I have any installed.  At least I couldn't find any of the
listed programs in Windows' remove programs dialog.

However I still get intermittent crashes when running things like make
or configure scripts.  These seem to occur only or more often if I have
more terminals open (mintty) and/or a few suspended programs (usually
vim and perhaps some verbose program piped into less).

I was wondering if anyone else had experience with this.  Can anyone
suggest something I should have a look at?  Is some Windows resource
being exhausted?  I used to have many explorer.exe processes running too
(from run explorer.exe with a path through a script) but now with just
one running I still encounter the problem.

A quick summary of my system:  Windows 7 x86-64 (fairly often updated),
Cygwin 2.4 x86-64.  The message I get is quoted below.  I have also
attached the cygcheck output.

> 0 [main] sh 10684 fork: child -1 - forked process 7812 died unexpectedly, 
> retry 0, exit code 0xC005, errno 11

Thanks.

Cygwin Configuration Diagnostics
Current System Time: Tue Feb 02 14:18:53 2016

Windows 7 Ultimate Ver 6.1 Build 7601 Service Pack 1

Path:   S:\cygwin\x86_64\usr\local\bin
S:\cygwin\x86_64\bin
C:\ProgramData\Oracle\Java\javapath
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\GnuPG\pub
C:\Program Files (x86)\PuTTY
C:\Program Files\ImageMagick-6.9.0-Q16
C:\Program Files (x86)\Graphviz2.38\bin
S:\cygwin\x86_64\bin
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files (x86)\Skype\Phone

Output from S:\cygwin\x86_64\bin\id.exe
UID: 197608(James) GID: 197121(None)
197121(None)   197609(HomeUsers)
545(Users) 4(INTERACTIVE)
66049(CONSOLE LOGON)   11(Authenticated Users)
15(This Organization)  113(Local account)
4095(CurrentSession)   66048(LOCAL)
262154(NTLM Authentication)401408(Medium Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

LIBRARY_PATH = '/usr/local/lib'
USER = 'James'
PWD = '/home/James'
HOME = '/home/James'

HOMEPATH = '\Users\James'
APPDATA = 'C:\Users\James\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'Bahamut'
SHELL = '/bin/bash'
TERM = 'xterm-256color'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 30 Stepping 5, GenuineIntel'
PROFILEREAD = 'true'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/Windows/system32'
ORIGINAL_PATH = 
'/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
 Files (x86)/GnuPG/pub:/cygdrive/c/Program Files 
(x86)/PuTTY:/cygdrive/c/Program Files/ImageMagick-6.9.0-Q16:/cygdrive/c/Program 
Files (x86)/Graphviz2.38/bin:/usr/bin:/cygdrive/c/Program Files (x86)/NVIDIA 
Corporation/PhysX/Common:/cygdrive/c/Program Files (x86)/Skype/Phone'
USERDOMAIN = 'Bahamut'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
!:: = '::\'
TEMP = '/tmp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
GIT_SSH = 'plink'
CCACHE_COMPRESS = '1'
USERNAME = 'James'
PROCESSOR_LEVEL = '6'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
LANG = 'en_GB.UTF-8'
USERPROFILE = 'C:\Users\James'
TZ = 'Europe/Paris'
GCC_COLORS = 
'error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
PS1 = '\e[0m\n\e]0;\h \w\a\e[32m✓ \e[37m0\e[32m \u@\h\e[33m \w\e[0m\n$ '
LOGONSERVER = '\\BAHAMUT'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'AMD64'
LOCALAPPDATA = 'C:\Users\James\AppData\Local'
ProgramData = 'C:\ProgramData'
EXECIGNORE = '*.dll'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/tmp'
SYSTEMROOT = 'C:\Windows'
PRINTER = '\\WILLIAMS-COMP\Canon MP630 series Printer'
PROCESSOR_REVISION = '1e05'
SOLARIZED = '1'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '4'
SESSIONNAME = 'Console'
COMPUTERNAME = 'BAHAMUT'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\R:\cygwin-x86'
  15cd0abf7540 = '\??\R:\cygwin-x86_64'
  6435883e1e7fe6b2 = '\??\C:\Program Files (x86)\Exact Audio Copy'
  3635de421b08faae = '\??\S:\cygwin\x86_64'
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions\FATE-cygwin64
  (default) = 0x0001
  HostName = 

Re: Fork and crashing problems

[Achim Gratz]

James Darnley  gmail.com> writes:
> > 0 [main] sh 10684 fork: child -1 - forked process 7812 died
unexpectedly, retry 0, exit code 0xC005,
> errno 11

Well, that exit code is ACCESS_VIOLATION... if you are sure it's not BLODA
related and it fails only intermittently and always with a different
program, I'd run a memory test.


Regards,
Achim.


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

Tmux man page not up to date

[Byron Boulton]

The man page for tmux in Cygwin is not up to date. The version of tmux
in cygwin is 2.1, but the man page is not consistent with that.

Specifically I noticed it because I was getting warnings about my mouse
configurations settings. There was a breaking change to this for tmux
2.1 as noted in the tmux changelog on their website.

Byron Boulton


--
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: Python stackdump on "succesful" exit after import of python-requests

[Maarten Jacobs]

Hi Robert,

My experience with Python is very, very limited. The only reason I am looking 
into this issue is because one of the packages I want to install won't work 
because of this :)

Therefore, if you could send me a sample Python script that causes the problem 
on your end, I'd be more than happy to try it out on my end and see if it 
causes the same issue... Without me having to learn how to write Python.

Your comment about a "fresh" install is intriguing and I will definitely try 
that out for myself. As an aside, I am running into this issue on a 32-bit 
install, is that where you found the problem initially?

Thanks,

Maarten


> From: robert.mart...@bell.ca
> To: maarten...@hotmail.com
> CC: cygwin@cygwin.com
> Subject: RE: Python stackdump on "succesful" exit after import of 
> python-requests
> Date: Tue, 2 Feb 2016 05:58:11 +
>
> Hello Maarten,
> I won't be a lot of help with the low level debugging here but I do have some 
> suggestions.
> The issue occurs for me whenever I import 'requests', could you try importing 
> that module in your tests see if it also happens to you?
>
> I'm wondering if this is just a common problem between modules or if it is 
> inherit in python itself.
>
> The other thing I noticed is that in a fresh install of 64 bit cygwin, the 
> issue does not occur!
>
> I'm going to see if I can isolate it further...
>
> Thanks for your help!
> --
> Robert Martens
> 613 807 6137
> ADMS System Administrator
>
> On Feb 1, 2016 9:05 PM, Maarten Jacobs  wrote:
> Still whittling away at this issue. I installed a few more debug libraries, 
> and the traceback now looks like:
>
> (gdb) r generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
> Starting program: /usr/bin/python generator.py libvirt 
> /usr/share/libvirt/api/libvirt-api.xml
> [New Thread 6688.0x730]
> [New Thread 6688.0x1d44]
> [New Thread 6688.0x1c68]
> [New Thread 6688.0x12d8]
> Found 406 functions in /usr/share/libvirt/api/libvirt-api.xml
> Found 0 functions in libvirt-override-api.xml
> Generated 338 wrapper functions
> Done!
>
> Program received signal SIGABRT, Aborted.
> 0x66b73de4 in Py_Exit () at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> 1780 exit(sts);
> (gdb) bt
> #0 0x66b73de4 in Py_Exit () at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> #1 0x76e8e091 in WaitForSingleObjectEx () from 
> /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
> #2 0x76e8dff2 in WaitForSingleObject () from 
> /cygdrive/c/WINDOWS/SYSTEM32/KERNELBASE.dll
> #3 0x610f2730 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 
> (p=p@entry=0x60fd, si=..., tls=tls@entry=0x0)
> at /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/sigproc.cc:716
> #4 0x610ef4cc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd, si=...) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:252
> #5 0x610ef9d8 in kill0 (pid=pid@entry=6688, si=...) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:303
> #6 0x610efbb2 in kill (sig=sig@entry=6, pid=6688) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:312
> #7 raise (sig=sig@entry=6) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:288
> #8 0x610efe79 in abort () at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/signal.cc:375
> #9 0x6deb43c1 in __deregister_frame_info_bases (begin=0x6e20 
> <__EH_FRAME_BEGIN__>) at 
> /usr/src/debug/gcc-4.9.3-1/libgcc/unwind-dw2-fde.c:216
> #10 0x6e1e10e2 in __gcc_deregister_frame () from /usr/bin/cygexpat-1.dll
> #11 0x61028bb7 in per_module::run_dtors (this=0x6130d658) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:81
> #12 dll::run_dtors (this=0x6130d650) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.h:72
> #13 dll_global_dtors () at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dll_init.cc:53
> #14 0x6118d64d in __call_exitprocs (code=code@entry=0, d=d@entry=0x0) at 
> /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/__call_atexit.c:118
> #15 0x6114ae88 in exit (code=0) at 
> /usr/src/debug/cygwin-2.4.1-1/newlib/libc/stdlib/exit.c:66
> #16 0x61006e79 in cygwin_exit (n=0) at 
> /usr/src/debug/cygwin-2.4.1-1/winsup/cygwin/dcrt0.cc:1337
> #17 0x610ebf85 in _sigfe () at sigfe.s:38
> #18 0x66b73de4 in Py_Exit (sts=sts@entry=0) at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780
> #19 0x66ba5281 in handle_system_exit () at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1152
> #20 0x66b7413e in handle_system_exit () at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1193
> #21 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars@entry=1) at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1162
> #22 0x66b74bc7 in PyErr_Print () at 
> /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1065
> #23 PyRun_SimpleFileExFlags (fp=, filename=0x60cc5c 
> "generator.py", closeit=1, flags=0x60cb5c)
> at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:953
> #24 0x66b8ae9e in Py_Main (argc=argc@entry=4, 

Tmux man page not up to date

[Byron Boulton]

The man page for tmux in Cygwin is not up to date. The version of tmux 
in cygwin is 2.1, but the man page is not consistent with that.


Specifically I noticed it because I was getting warnings about my mouse 
configurations settings. There was a breaking change to this for tmux 
2.1 as noted in the tmux changelog on their website.


Byron Boulton


--
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: Defining _GNU_SOURCE hides the declaration of aligned_alloc

[Yaakov Selkowitz]

On 2016-02-02 16:27, Ken Brown wrote:

The issue in the Subject line came up in connection with an emacs bug
report.

Here's a test case:

[snip]

$ gcc test.c -Wimplicit-function-declaration
test.c: In function ‘main’:
test.c:7:3: warning: implicit declaration of function ‘aligned_alloc’

The cause is that the declaration of aligned_alloc in stdlib.h is
guarded by #if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L; but
defining _GNU_SOURCE causes __ISO_C_VISIBLE to be defined as 1999.
Here's an excerpt from /usr/include/sys/cdefs.h showing how this happens:

[snip]

According to the discussion of the emacs bug I mentioned, Linux and
FreeBSD don't have this issue.  Should Cygwin's headers be changed to
conform to those other platforms?


Yes, it should.  I have added this to my queue of such fixes, which I 
hope to post soon.


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