public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-apps@cygwin.com
Subject: Re: Help needed with wxWidgets3.1 tests compilation error
Date: Thu, 20 Jan 2022 13:38:40 -0700	[thread overview]
Message-ID: <c63774dd-5e5f-2a15-414d-626de7168aac@SystematicSw.ab.ca> (raw)
In-Reply-To: <DB3PR0202MB3561BC413686BBECBDD2991EE75A9@DB3PR0202MB3561.eurprd02.prod.outlook.com>

On 2022-01-20 10:10, Hamish McIntyre-Bhatty wrote:
> I've been having trouble compiling the unit tests for wxWidgets3.1-3.1.5 
> on Cygwin. The same tests build just fine on my Linux Mint 20.3 install, 
> however that is using GCC 9.3.0 instead of Cygwin's 11.2.0.
> 
> Attached is the full build log, but I will also point out my ideas about 
> particular issues here.
> 
> Note: -Werror=format-security is used in the Makefile. I couldn't find 
> exactly what this does, but I'm probably looking in the wrong place - 
> the manpage. Perhaps the following could also be explained by 
> differences from GCC 9 to 11?

I check first as in `info GCC Wformat-security` should only care about 
*printf string variables without using a separate format string.

> The first is:
> 
> In file included from /usr/include/unistd.h:4,
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: 
> 
> /usr/include/sys/unistd.h:23:9: error: redundant redeclaration of ‘int 
> chmod(const char*, mode_t)’ in same scope [-Werror=redundant-decls]
>     23 | int     chmod (const char *__path, mode_t __mode);
>        |         ^~~~~
> In file included from /usr/include/sys/_default_fcntl.h:211,
>                   from /usr/include/sys/fcntl.h:3,
>                   from /usr/include/fcntl.h:12,
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:83: 
> 
> /usr/include/sys/stat.h:137:9: note: previous declaration of ‘int 
> chmod(const char*, mode_t)’
>    137 | int     chmod (const char *__path, mode_t __mode );
>        |         ^~~~~
> 
> This doesn't happen on my Linux Mint 20.3 (Ubuntu 20.04) host, so I'm 
> assuming this is something to do with the standard library?
> 
> Next is:
> 
> In file included from /usr/include/unistd.h:4,
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/filefn.h:23, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/utils.h:20, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/cursor.h:75, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/event.h:22, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/include/wx/evtloop.h:14, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/testprec.h:5, 
> 
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:433: 
> 
> /usr/include/sys/unistd.h:179:9: error: redundant redeclaration of ‘int 
> pthread_atfork(void (*)(), void (*)(), void (*)())’ in same scope 
> [-Werror=redundant-decls]
>    179 | int     pthread_atfork (void (*)(void), void (*)(void), void 
> (*)(void));
>        |         ^~~~~~~~~~~~~~
> In file included from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35, 
> 
>                   from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148, 
> 
>                   from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35,
>                   from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39,
>                   from 
> /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iomanip:40,
>                   from 
> /home/Hamis/wxwidgets3.1/wxWidgets3.1-3.1.5-1.x86_64/src/wxWidgets-3.1.5/tests/allheaders.cpp:63: 
> 
> /usr/include/pthread.h:65:5: note: previous declaration of ‘int 
> pthread_atfork(void (*)(), void (*)(), void (*)())’
>     65 | int pthread_atfork (void (*)(void), void (*)(void), void 
> (*)(void));
>        |     ^~~~~~~~~~~~~~
> 
> Ditto.

Looking at chmod(3p), pthread_atfork(3p), pthread.h(0p) sys_stat.h(0p), 
unistd.h(0p) those definitions should *NOT* normally be accessible from 
unistd.h so there should be no conflict, as POSIX specifies what is 
visible.
Perhaps they are there for compatibility with older systems like BSD or 
Solaris and should be suppressed when newer feature macros are defined 
or specific legacy system macros are not defined?

> Also of note, is that Cygwin is several times slower at compiling pretty 
> much everything for me. Does anyone know if this is GCC 9 vs 11 speed, 
> or running Cygwin in Windows 11 in KVM, or something else? I am running 
> on AMD Ryzen 3000, if that has anything to do with it.

VM is always slower than native, Windows than Linux, Cygwin than 
Windows, maybe see if Cygwin under Wine is faster than under Windows in 
KVM?
Windows 11 may have more instrumentation than 10 especially if Developer 
or Insider edition.
Windows performance profile, desktop/laptop busses, CPU count, MT, 
speed, memory, SSD/HDD will also have effects.

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

  reply	other threads:[~2022-01-20 20:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-20 17:10 Hamish McIntyre-Bhatty
2022-01-20 20:38 ` Brian Inglis [this message]
2022-01-21 10:08   ` Hamish McIntyre-Bhatty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c63774dd-5e5f-2a15-414d-626de7168aac@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).