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: 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.