Bug 1196556

Summary: building gnutls guile binding fails in rawhide
Product: [Fedora] Fedora Reporter: Nikos Mavrogiannopoulos <nmavrogi>
Component: gnutlsAssignee: Nikos Mavrogiannopoulos <nmavrogi>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: 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 Flags
testsuite log none

Description Nikos Mavrogiannopoulos 2015-02-26 09:40:09 UTC
Created attachment 995497 [details]
testsuite log

Description of problem:
The version of guile in rawhide breaks the build of gnutls' guile bindings. The guile test programs fail to execute:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9080130

The test suite log is attached, and the guile used is: 5:2.0.11-5.fc23 
(In F22 it builds fine with 5:2.0.11-4.fc22)

Comment 1 Nikos Mavrogiannopoulos 2015-02-26 09:41:37 UTC
Interestingly the only difference in rawhide seems to be:
https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code

Comment 2 Nikos Mavrogiannopoulos 2015-02-26 09:52:44 UTC
Adding Till Maas who did the rebuild. Most probably guile should include %global _hardened_build 0 for the interpreter.

Comment 3 Miroslav Lichvar 2015-03-06 13:58:16 UTC
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.

Comment 4 Nikos Mavrogiannopoulos 2015-03-06 15:38:51 UTC
I don't see how can a shared guile module can be affected by these flags. A shared library is already position independent.

Comment 5 Nikos Mavrogiannopoulos 2015-03-06 16:27:23 UTC
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.

Comment 6 Moez Roy 2015-03-14 03:15:20 UTC
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)

Comment 7 Jan Synacek 2015-03-17 11:45:03 UTC
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.

Comment 8 Moez Roy 2015-03-18 16:00:44 UTC
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.

Comment 9 Moez Roy 2015-03-20 02:23:12 UTC
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

Comment 10 Moez Roy 2015-03-20 05:19:42 UTC
(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

Comment 11 Nikos Mavrogiannopoulos 2015-03-20 09:39:20 UTC
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.