Failing build when using binutils 2.34-1 on Cygwin 32/64-bit
I maintain numerous projects, as part of that I've set up CI tests that use current Cygwin 32-bit and 64-bit. Recently I've noticed that builds were failing with errors like: https://ci.appveyor.com/project/libyal/libfwsi/build/job/7b822r4j4ghfs2m5#L953 /usr/lib/gcc/i686-pc-cygwin/9.2.0/../../../../i686-pc-cygwin/bin/ld: fwsi_test_error.o: in function `fwsi_test_error_sprint': /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to `_imp__libfwsi_error_sprint' https://ci.appveyor.com/project/libyal/libfwsi/build/job/3qnu5pk3lm4u12pe#L960 /home/appveyor/libfwsi/tests/fwsi_test_error.c:72: undefined reference to `__imp_libfwsi_error_sprint' /home/appveyor/libfwsi/tests/fwsi_test_error.c:72:(.text.startup+0x24): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_libfwsi_error_sprint' Since I did not make significant changes to the project sources I started analyzing the build environment. I was able to reproduce the issues with binutils 2.34-1 on Cygwin 64-bit on a separate Windows 10 installation. When I reverted to binutils 2.31-1 the build issues do NOT surface. I suspect a change or issue with binutils 2.34-1 is causing the build issues. Happy to provide additional details / help troubleshooting where possible. Kind regards, Joachim P.S. I tried searching for duplicate issues on https://sourceware.org/cgi-bin/search.cgi?form=extended&qprev= unfortunately it returns a lot of results and starts with the oldest results first. Small request for the future, consider adding an option to return results in reverse order. Tracking this for the libyal projects in https://github.com/libyal/libyal/issues/83 -- 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: gcc segfaults compiling python extensions
> Was there a stackdump file you could have attached? What happens if you > remove the -O3 and -O2 for that matter. I find it interesting that > you're using a 32bit Cygwin on a server that only executes on a 64bit > CPU. Does this happen with 64bit Cygwin? No, then use it instead. So this does not happen on 64-bit Cygwin. I use both this is part of CI testing I want to have the code compile on both, or skip the test scenario. > So some anomaly in Windows itself was resolved. Should we really worry > about such an issue in Cygwin? Only if Cygwin is using some API that is > only available in Windows Server 2016 is my POV. Recent similar failures have me think the issue is still there even on newer versions of Windows. https://ci.appveyor.com/project/joachimmetz/libfwsi/build/job/ljhihmejb6xfyaqe > You could try debugging the failures. Follow the gcc issue with an > strace of the processes. Attach the stackdump file if one was created, etc. Seeing the issue seems to be still there, when time permits, I'll see what information I can collect regarding this issue and update this thread. -- 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
gcc segfaults compiling python extensions
Hello CygWin maintainers, I want to report an observation, which might help address a bug. This issue has been reported in the past in: https://cygwin.com/ml/cygwin/2014-10/msg00502.html I recently ran into the same issue: On AppVeyor [https://ci.appveyor.com/] running Windows Server 2012 R2 With the latest available cygwin 32-bit [https://github.com/libyal/libfwnt/blob/master/appveyor.yml#L39] building a Python module for CygWin python (no Windows Python) causes gcc to SIGSEGV (11) gcc -fno-strict-aliasing -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/build=/usr/src/debug/python2-2.7.13-1 -fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/src/Python-2.7.13=/usr/src/debug/python2-2.7.13-1 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_CONFIG_H= -DLOCALEDIR="/usr/share/locale" -Iinclude -Icommon -Ilibcerror -Ilibcthreads -Ilibcdata -Ilibcnotify -Ilibfwnt -I/usr/include/python2.7 -c libcerror/libcerror_error.c -o build/temp.cygwin-2.8.2-i686-2.7/libcerror/libcerror_error.o error: command 'gcc' terminated by signal 11 Running: 'setup.py build' failed Also see: https://ci.appveyor.com/project/joachimmetz/libfwnt/build/79/job/l1gqocdqoafax0k7 As per: https://cygwin.com/ml/cygwin/2014-10/msg00552.html I switched to Windows Server 2016 and this indeed does not show the same issue. I've been tracking this in: https://github.com/libyal/libyal/issues/34 Hope to have sufficiently informed you. Let me know if you need additional information. Kind regards, Joachim -- 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
