Description of problem: When building gnutls on Fedora rawhide for ARM three tests fail during 'make check'. Version-Release number of selected component (if applicable): gnutls-2.12.14 gcc-4.7.0 glibc-2.15 guile-1.8.8 How reproducible: Always Steps to Reproduce: 1. submit a build in arm.koji or in an ARM mock chroot 2. 3. Actual results: make check-TESTS make[3]: Entering directory `/builddir/build/BUILD/gnutls-2.12.14/guile/tests' PASS: anonymous-auth.scm /bin/sh: line 5: 11417 Segmentation fault GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst FAIL: session-record-port.scm PASS: pkcs-import-export.scm PASS: errors.scm PASS: x509-certificates.scm /bin/sh: line 5: 11463 Segmentation fault GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst FAIL: x509-auth.scm PASS: openpgp-keys.scm PASS: openpgp-keyring.scm /bin/sh: line 5: 11499 Segmentation fault GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst FAIL: openpgp-auth.scm =================================== 3 of 9 tests failed Please report to bug-gnutls =================================== Expected results: make check-TESTS make[3]: Entering directory `/builddir/build/BUILD/gnutls-2.12.14/guile/tests' PASS: anonymous-auth.scm PASS: session-record-port.scm PASS: pkcs-import-export.scm PASS: errors.scm PASS: x509-certificates.scm PASS: x509-auth.scm PASS: openpgp-keys.scm PASS: openpgp-keyring.scm PASS: openpgp-auth.scm ================== All 9 tests passed ================== Additional info: This appears to be caused by a difference in the size of off_t in the following structure: /usr/include/libguile/ports.h ------------------------------------- typedef struct { SCM port; long int entry; int revealed; scm_t_bits stream; SCM file_name; long int line_number; int column_number; unsigned char *read_buf; const unsigned char *read_pos; unsigned char *read_end; off_t read_buf_size; unsigned char *saved_read_buf; const unsigned char *saved_read_pos; unsigned char *saved_read_end; off_t saved_read_buf_size; unsigned char *write_buf; unsigned char *write_pos; unsigned char *write_end; off_t write_buf_size; unsigned char shortbuf; int rw_random; scm_t_port_rw_active rw_active; unsigned char *putback_buf; size_t putback_buf_size; } scm_t_port; ------------------------------------- In gnutls off_t is 'long long int', but in guile off_t is 'long int'. This is because gnutls has: #define _FILE_OFFSET_BITS 64 and guile has no such definition. By building guile with -D_FILE_OFFSET_BITS=64, the gnutls test completed successfully. Conversely, using the original guile build and rebuilding gnutls with '--disable-largefile' in the configure command also allows the gnutls tests to complete successfully. The difference in size of off_t is also true for x86, but due to the alignment of elements in the structure, no error occurs in the tests. Specifically, putback_buf pointer contains 0x0 (NULL), which allows the tests to succeed. On ARM it is non-zero, which causes the segfault when the memory at the pointer is freed. I have also submitted this bug to bug-gnutls.
Created attachment 559360 [details] Disable large file support for ARM builds.
Commited the change in comment 1 for now for arm.
Thanks David!
I really wonder what is the correct thing to do here. Wouldn't it be more proper to build guile with the define? Although it would mean that the define would be also required for other guile modules which use the off_t type.
gnutls actually performs a check (during configure) to determine what sizes should be set, and if large file support should be included. If guile, and other related packages, performed the same check(s), they should at least all be consistent within an arch, and I think that would address the problem. I think the concern now is how to implement such a change without breaking compatibility with existing released packages. Since ARM does not have existing released packages, making the above change was the easiest work-around, with the least impact on other archs, at least for now. I agree, fixing guile and other related packages is the better long term fix.
I don't think we can build gnutls without largefile support on x86 and doing it on arm can be seen only as temporary workaround. The correct thing would be to recompile guile and its dependencies with the largefile support in F18. If guile maintainers do not agree the only remaining correct solution I can see is to disable the build of guile bindings in gnutls - I do not see any package depending on them in F16 anyway.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.