Bug 1196556 - building gnutls guile binding fails in rawhide
Summary: building gnutls guile binding fails in rawhide
Alias: None
Product: Fedora
Classification: Fedora
Component: gnutls
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Nikos Mavrogiannopoulos
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: harden-failure
TreeView+ depends on / blocked
Reported: 2015-02-26 09:40 UTC by Nikos Mavrogiannopoulos
Modified: 2015-03-20 10:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-03-20 10:05:53 UTC
Type: Bug

Attachments (Terms of Use)
testsuite log (18.37 KB, text/plain)
2015-02-26 09:40 UTC, Nikos Mavrogiannopoulos
no flags Details

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:

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:

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:


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:


export CFLAGS

and the latest version builds successfully:


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.

Note You need to log in before you can comment on or make changes to this bug.