Re: CI system cryptic error
On 21.01.2022 17:03, Hamish McIntyre-Bhatty wrote: On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish I saw something similar but I do not remember the details. Cygport is looking for something that has changed name or it is not available anymore. Probably the old name is still used by Python2 and it is the reason why the error seldom show up in local build of maintainers. cygport --debug should provide some hints
Re: python-numpy (1.22.0-1) can't be imported
On 22.01.2022 02:04, Masamichi Hosoda wrote: I have not found the root cause yet. As the 1.21.4-1 imports correctly I removed the 1.22.0-1 until I solve the issue. I do not see anything obvious in upstream source between 1.21.4 and 1.22.0 that gives me any hint on root cause. Also 1.22.1 shows the same problem. I excluded the build chain as rebuilding 1.19.4 worked fine for all 3.6 to 3.9 If I understand correctly, the patch below is just a quick hack, but it solves the problem. ``` --- a/numpy/random/setup.py +++ b/numpy/random/setup.py @@ -147,7 +147,8 @@ include_dirs=['.', 'src', 'src/legacy'], libraries=mtrand_libs, extra_compile_args=EXTRA_COMPILE_ARGS, - extra_link_args=EXTRA_LINK_ARGS, + extra_link_args=(EXTRA_LINK_ARGS + + ['-Wl,--export-all-symbols']), depends=depends + ['mtrand.pyx'], define_macros=defs + LEGACY_DEFS, ) ``` Thanks It is something like that, but "-Wl,--export-all-symbols" is not used on 1.21.4 and is not needed for most of the other modules on 1.22.x so I am looking for a less extreme action. Also to understand how it can impact other python subpackages Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: python-numpy (1.22.0-1) can't be imported
> I have not found the root cause yet. > As the 1.21.4-1 imports correctly I removed the 1.22.0-1 until I solve > the issue. > > I do not see anything obvious in upstream source between 1.21.4 and > 1.22.0 that gives me any hint on root cause. > > Also 1.22.1 shows the same problem. > I excluded the build chain as rebuilding 1.19.4 worked fine > for all 3.6 to 3.9 If I understand correctly, the patch below is just a quick hack, but it solves the problem. ``` --- a/numpy/random/setup.py +++ b/numpy/random/setup.py @@ -147,7 +147,8 @@ include_dirs=['.', 'src', 'src/legacy'], libraries=mtrand_libs, extra_compile_args=EXTRA_COMPILE_ARGS, - extra_link_args=EXTRA_LINK_ARGS, + extra_link_args=(EXTRA_LINK_ARGS + + ['-Wl,--export-all-symbols']), depends=depends + ['mtrand.pyx'], define_macros=defs + LEGACY_DEFS, ) ``` -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mpg123 delayed reaction to keyboard
On Fri, 21 Jan 2022 23:40:49 +0900 Takashi Yano wrote: > On Thu, 20 Jan 2022 11:06:04 + > Миронов Леонид Владимирович wrote: > > mpg123 reacts to keyboard commands after a ~3 second delay while playing > > but not when paused i.e. when spacebar is pressed while music is playing it > > stops after 3 seconds but when spacebar is pressed again it resumes playing > > instantaneously. No such issue on linux with the same 1.25.10. Changing > > buffer size (-b) has no effect. > > In my environment, the same happens even in Linux. > This looks upstream problem of mpg123. Ah, this seems to depend on audio output module. If output module is pulse or alsa, this does not happen, but DOES happen with oss. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: CMake support into libssh-0.8.7-1 is broken.
Hello, Il giorno gio 20 gen 2022 alle ore 20:07 Marco Atzeri ha scritto: > > On 15.01.2022 14:19, Marco Atzeri wrote: > > On 14.01.2022 23:30, Carlo B. wrote: > >> Hello, > >> I discovered that CMake support into current libssh-0.8.7-1 is broken. > >> After you installed the development package, you just need to add this > >> line into a dummy CMakeLists.txt: > >> > >> > >> find_package(libssh) > >> > >> > > >> > >> So, I downloaded the latest sources from the repository: GCC still > >> emits an internal compiler error, but only when building the examples. > >> So I configured with -DWITH_EXAMPLES=OFF and I got the base library > >> compiled. > >> Here, I verified that the macros for CMake are generated correctly > >> with the right names and paths. > >> > >> Is it possible to fix or update this package? > >> Thank you very much for your time. > >> > >> Sincerely. > >> > > > > noted > > > > Regards > > Marco > > > > what´s happening if you try to use libssh2 ? > Thank you for the reply. Unfortunately, I doubt that it can be possible because libssh is required for building Codelite for CYGWIN. About the crash of CYGWIN GCC when building the latest source of libssh, this is caused by the "-fstack-clash-protection" option. However, according to this issue at bugzilla for GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 it should not be used when the target platform is Windows and derivates. > Currently libssh is without maintainer and it is anyway obsolete > so probably you should build with libssh2 > This is a bad news actually, I mean the missing maintaner. Sincerely. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-????
On 2022/01/19 17:01, Ken Whitesell wrote:
On 1/19/2022 2:28 PM, Jon Turney wrote:
On 19/01/2022 00:02, Ken Whitesell wrote:
On 1/17/2022 1:29 PM, Ken Whitesell wrote:
After more research and experimentation, it appears to be related to
one of xorg-server, xorg-server-common, or xorg-server-xorg.
Installing the older version 1.20.12-1 of these packages allows the
windows to be moved between monitors without any issues. Upgrading to
the current version 21.1.3-1 creates the problems. I'm able to
replicate this behavior on two different laptops with two different
external monitors.
It seems likely that this is an unintended effect of changes in
xorg-server 21.1.0-1, trying to fix problems in this area (See [1])
I am seeing this issue or one very much like it on Win7x64
But I have 1.20.12-1 of xorg-server + xorg-server{,-common,-debuginfo},
but I do not have xorg-server-xorg installed *at all*.
Mine has nothing to do with moving windows between monitors.
I'm seeing truncated windows on my main monitor (2560x1440).
My 2nd monitor is 1920x1080.
On boot, I start the Xserver by calling ~/bin/Xserver.sh
I use a modified Xserver.sh script that was no longer being called
due to a "Xserver.sh.lnk" being in ~/bin that pointed to the system
script in /bin. Ooops.
Upon fixing that problem, the problem of X-apps no longer updating correctly
disappeared.
My script has a few diffs and is missing the xauth stuff..
It's about 6 years old, and hasn't been cleaned up for public consumption,
but it works.
Point being, that for me, the problem seems to have been worked around
in the startup script.
Caveat -- my X-apps don't update in my 2nd window, so there's still some
lemon in my setup, but I haven't taken the time to figure it out as my 2nd
Screen is on the wall and used for video -- it's too far away for me to
read text on it, so I haven't bothered to chase down the lack of updates (I
can drag a window over to the 2nd screen and that displays fine, but
Xupdates
don't.
Getting it to work properly might be a problem since the DPI on the 2nd
monitor
is different than on the 1st one. I hear Win10 has allowances for different
DPI screens.
Thw two Xwin.logs are from the cygwin startup script (.orig) and my startup
script. The cygwin script seems end up sizing my 2560x1440 screen down to
1920x1080, which corresponds to the dead area in updating X-apps I was
seeing.
update
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.12.0
OS: CYGWIN_NT-6.1-7601 ATHENAE 3.2.0-340.x86_64 2021-03-29 08:42 UTC x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64)
Package: version 1.20.12-1 built 2021-07-11
XWin was started with the following command line:
/usr/bin/XWin -dpi 120 -listen tcp -nopn +iglx -wgl -compositealpha
-compositewm -lesspointer -clipboard -ac -unixkill -nowinkill
-multiwindow -wm -ardelay 150 -arinterval 30 +bs -nomultimonitors
-hostintitle -noreset -logverbose 2 -fp
/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts
ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 2560 h 1440
winInitializeScreenDefaults - native DPI x 120 y 120
[438305.291] (II) xorg.conf is not supported
[438305.291] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more
information
[438305.291] (++) FontPath set to
"/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts"
[438305.291] LoadPreferences: Loading /Users/law.Bliss/.XWinrc
[438305.291] LoadPreferences: Done parsing the configuration file...
[438305.291] winDetectSupportedEngines - RemoteSession: no
[438305.369] winDetectSupportedEngines - DirectDraw4 installed, allowing
ShadowDDNL
[438305.385] winDetectSupportedEngines - Returning, supported engines 0005
[438305.385] winSetEngine - Multi Window or Rootless => ShadowGDI
[438305.385] winScreenInit - Using Windows display depth of 32 bits per pixel
[438306.883] winAllocateFBShadowGDI - Creating DIB with width: 2560 height:
1440 depth: 32
[438306.883] winFinishScreenInitFB - Masks: 00ff ff00 00ff
[438306.883] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8
d 24 bpp 32
[438306.898] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[438307.163] (II) AIGLX: Testing pixelFormatIndex 5
[438307.273] GL_VERSION: 4.6.0 NVIDIA 441.41
[438307.273] GL_VENDOR: NVIDIA Corporation
[438307.273] GL_RENDERER:GeForce RTX 2080 Ti/PCIe/SSE2
[438307.273] (II) GLX: enabled GLX_SGI_make_current_read
[438307.273] (II) GLX: enabled GLX_SGI_swap_control
[438307.273] (II) GLX: enabled GLX_MESA_swap_control
[438307.273] (II) GLX: enabled GLX_SGIX_pbuffer
[438307.273] (II) GLX: enabled GLX_ARB_multisample
[438307.273] (II) GLX: enabled GLX_SGIS_multisample
[438307.273] (II) GLX: enabled GLX_ARB_fbconfig_float
Re: CI system cryptic error
On 21/01/2022 14:06, Jon Turney wrote: On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 Yep, sorry I forgot to add the link. In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. No I did a local i686 build too, and it was fine... This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why! Hmm, very strange. Maybe just a freak error? I'll try building again, seeing as I have a new version now anyway, and see what happens. I guess seeing as 64-bit builds are the future for Cygwin, I'll just ignore this issue if it happens again, as long as I check the 32-bit builds I built work. Hamish
Re: Newname====($"NULL"$)====PROTOTYPE====CALAVARY LOGGER====0.0.0.0====0X0000000====NTATHORITY_SECURITY 0X0====MY RAW VIRTUAL STATIC SIGNATURE. YOU ALL OWE ME MONEY.!!!!!! ELSE GLOBALINFRASTRUCTUREEM
Null On Sat, Jan 15, 2022, 4:55 AM Null Bug wrote: > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: mpg123 delayed reaction to keyboard
On Thu, 20 Jan 2022 11:06:04 + Миронов Леонид Владимирович wrote: > mpg123 reacts to keyboard commands after a ~3 second delay while playing but > not when paused i.e. when spacebar is pressed while music is playing it stops > after 3 seconds but when spacebar is pressed again it resumes playing > instantaneously. No such issue on linux with the same 1.25.10. Changing > buffer size (-b) has no effect. In my environment, the same happens even in Linux. This looks upstream problem of mpg123. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: CI system cryptic error
On 20/01/2022 15:50, Hamish McIntyre-Bhatty wrote: Hi there, Recently, I created a test package for python-imaging, and the CI system gave a build error that I didn't see locally: *** ERROR: unknown wheel filename. This only occurred for the Python 3.8 build (3.6 and 3.7 are unaffected). Considering some of the library name changes between these versions, is it possible that this is a bug in the CI tool setup or in cygport? Weird. I assume it's this job: https://github.com/cygwin/scallywag/actions/runs/1592256829 In which case further note it only failed with this error on i686, x86_64 seems to have built ok. That might explain why you don't see it locally, at least, but it's still puzzling that there's a difference. This error comes from here: https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=blob;f=cygclass/python-wheel.cygclass;h=90b0faac71eea6005401b4232e5b334bdc81b756;hb=HEAD#l190 and means something more like "couldn't find the wheel file for python $ver" I downloaded the builddir archive, and inspecting that it seems that a wheel for python3.8 (and 3.9!) isn't being generated. $ tar -tf builddir.tar.xz | grep whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp36-cp36m-cygwin_3_3_3_i686.whl python-imaging-8.4.0-1.i686/build/dist/Pillow-8.4.0-cp37-cp37m-cygwin_3_3_3_i686.whl There seems to be completely different output between x86_64 and i686 when building the python wheel, but I have no idea why!
Re: Duplicate ACLs? - Can't copy file even with Admin permissions
Hi Corinna, I found another file with ACLs that fail even under the new snapshot cygwin1.dll. #getfacl setup.ilg # file: setup.ilg # owner: Administrators # group: None getfacl: setup.ilg: Invalid argument #icacls.exe setup.ilg setup.ilg NT SERVICE\TrustedInstaller:(I)(F) NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Administrators:(I)(OI)(CI)(IO)(F) BUILTIN\Users:(I)(RX) BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE) CREATOR OWNER:(I)(OI)(CI)(IO)(F) #icacls.exe setup.ilg /save setup.acl #cat setup.acl setup.ilg D:(A;ID;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIOID;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;0x1200a9;;;BU)(A;OICIIOID;GXGR;;;BU)(A;OICIIOID;GA;;;CO) - Any thoughts on what might be wrong here? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ITP] biosig [was: Re: newcomer issues when packaging biosig, stimfit, etc.]
On 20/01/2022 20:48, Alois Schlögl wrote: In order to use the playgroun, I guess I need to provide my ssh key. Here it is: Name: Alois Schloegl BEGIN SSH2 PUBLIC KEY C3NzaC1lZDI1NTE5ILKBmNf1QN3lStTwpn46QIip7sS6zNKy0rG8WCYHv/ZU END SSH2 PUBLIC KEY Done. Updating ssh key for Alois Schloegl Fingerprint: 256 SHA256:bvMkxeY5KcLLESayAW43ZPOiYI9owtf0UKKWIWmue00 no comment (ED25519)
Re: A change to how calm expires packages
On 20/01/2022 14:33, Jon Turney wrote: To try to avoid packages lingering in the 'test' status indefinitely (which leads to them not being installed by most users, as they don't run setup with 'consider test packages' enabled, thus these packages generally aren't getting used, so having them isn't generating much value), I'm planning to change how calm expires packages: Currently (in the absence of configuration otherwise [1]), calm will retain up to 3 non-test versions, and 3 test versions, and expire all other versions. I plan to change this to also expire test versions which are superseded by a non-test version (that is: expire test versions where a non-test version with a higher version number exists). I believe this makes the default behaviour closer to what package maintainers are likely to want to happen. This change will cause the following packages to be removed: _autorebase-001091-0.1 cygutils-1.4.16-4 cygwin-3.3.0-0.1.9814cfd8f693 cygwin-3.3.0-0.2.6c1f49f83fde fontforge-20201107p2-1 fontforge-20201107p8-1 gcc-11.2.0-0 grep-3.6-1 grep-3.7-1 gzip-1.10-1 libftdi1-1.4-1 libiconv-1.16-1 meson-0.54.2-3 mingw64-i686-gcc-11.1.0-0.1 mingw64-i686-gcc-11.2.0-0 mingw64-i686-gcc-7.3.0-1 mingw64-x86_64-gcc-11.1.0-0.1 mingw64-x86_64-gcc-11.2.0-0.1 mingw64-x86_64-gcc-7.3.0-1 openbabel-3.1.1p36-1 openbabel-3.1.1p36-2 rdiff-backup-2.0.0-1 readline-8.1-1 screen-4.6.2-3 texlive-collection-latexrecommended-doc-20210118-2 xorg-server-21.1.0-1 Brian, Ken, The only packages I can see where this seems like it will do the wrong thing are listed below. Before deploying this, would you like me to:? grep: untest 3.6-1 and expire 3.0.1 gzip: untest 1.10-1 and expire 1.7-2 texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 20210118-1 [1] See https://cygwin.com/packaging-hint-files.html#override.hint. Not that override.hint files do not apply recursively currently. This seems like a good change to me, also.
Re: Help needed with wxWidgets3.1 tests compilation error
On 20/01/2022 20:38, Brian Inglis wrote: 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. Ah okay, I guess that doesn't explain the -Werror=zero-as-null-pointer-constant errors later. I guess that might be a GCC default change. 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
[ANNOUNCEMENT] libfido2 1.10.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.10.0-1 * libfido2-devel-1.10.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
libfido2 1.10.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.10.0-1 * libfido2-devel-1.10.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols.
