Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1196556
Summary: | building gnutls guile binding fails in rawhide | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nikos Mavrogiannopoulos <nmavrogi> | ||||
Component: | gnutls | Assignee: | Nikos Mavrogiannopoulos <nmavrogi> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | jsynacek, mlichvar, moez.roy, nmavrogi, opensource, tmraz | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-03-20 10:05:53 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1199775 | ||||||
Attachments: |
|
Description
Nikos Mavrogiannopoulos
2015-02-26 09:40:09 UTC
Interestingly the only difference in rawhide seems to be: https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code Adding Till Maas who did the rebuild. Most probably guile should include %global _hardened_build 0 for the interpreter. In a test with non-hardened guile and hardened gnutls it failed to build too, so it looks like it's something broken in gnutls. I don't see how can a shared guile module can be affected by these flags. A shared library is already position independent. Moreover, mockbuild with exactly the same flags succeeds, while the build on scratch fails http://koji.fedoraproject.org/koji/taskinfo?taskID=9157206 As the flags are exactly the same, I suppose it is an issue on the toolchain in f23, or in the actual flags used. libtool: link: (cd ".libs" && rm -f "libgnutls.so.28" && ln -s "libgnutls.so.28.41.5" "libgnutls.so.28") libtool: link: (cd ".libs" && rm -f "libgnutls.so" && ln -s "libgnutls.so.28.41.5" "libgnutls.so") libtool: link: ( cd ".libs" && rm -f "libgnutls.la" && ln -s "../libgnutls.la" "libgnutls.la" ) /bin/sh ../libtool --tag=CXX --mode=link g++ -I./includes -I./includes -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fPIC -pie -no-undefined -version-info 29:0:1 -Wl,-z,relro -Wl,-z,now -pie -o libgnutlsxx.la -rpath /usr/lib64 libgnutlsxx_la-gnutlsxx.lo libgnutls.la libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/5.0.0/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-redhat-linux/5.0.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.0.0/crtbeginS.o .libs/libgnutlsxx_la-gnutlsxx.o -Wl,-rpath -Wl,/builddir/build/BUILD/gnutls-3.3.13/lib/.libs ./.libs/libgnutls.so -L/usr/lib/gcc/x86_64-redhat-linux/5.0.0 -L/usr/lib/gcc/x86_64-redhat-linux/5.0.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.0.0/../../.. -lstdc++ -lm -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/5.0.0/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/5.0.0/../../../../lib64/crtn.o -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -O2 -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libgnutlsxx.so.28 -o .libs/libgnutlsxx.so.28.1.0 /usr/lib64/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init': (.text+0xe): undefined reference to `__init_array_start' /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): relocation R_X86_64_PC32 against undefined hidden symbol `__init_array_start' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Makefile:1620: recipe for target 'libgnutlsxx.la' failed make[4]: *** [libgnutlsxx.la] Error 1 make[4]: Leaving directory '/builddir/build/BUILD/gnutls-3.3.13/lib' Makefile:1810: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/builddir/build/BUILD/gnutls-3.3.13/lib' Makefile:1544: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/builddir/build/BUILD/gnutls-3.3.13/lib' Makefile:1381: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/gnutls-3.3.13' Makefile:1308: recipe for target 'all' failed make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.sC3kd0 (%build) I think that I've already seen something similar, but I don't know where. With gcc5, I think that you cannot use "-pie" when building libraries. Why are you using -Wl,--no-add-needed in the LD flags? I am able to get much further ahead in the build process when I remove this. I changed the first 2 lines in the spec file to: %global without dane %global without guile and the latest version builds successfully: https://koji.fedoraproject.org/koji/taskinfo?taskID=9276305 (In reply to Moez Roy from comment #9) > I changed the first 2 lines in the spec file to: > > %global without dane > %global without guile > > and the latest version builds successfully: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=9276305 Solution 2: Keep the guile bindings at the cost of disabling -z now: I added the following under %build in the spec file: CFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy" CXXFLAGS="$RPM_OPT_FLAGS -Wl,-z,lazy" export CFLAGS export CXXFLAGS and the latest version builds successfully: https://koji.fedoraproject.org/koji/taskinfo?taskID=9276929 Disabling the packages is not a solution :) I used the second one. However I doubt that this issue is restricted to gnutls-guile bindings. The best would be to have a special macro for applications that rely on modules with undefined symbols. That must be mentioned in the packaging guidelines. |