[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Jan Kundrát]

> Without this patch, I cannot build the toolchain (both host-gcc-initial
> and -final) on Gentoo's amd64 using GCC 4.9.3:
>
>   
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld:
>   gcov.o: relocation R_X86_64_32 against `.rodata.str1.8' can not
>   be used when making a shared object; recompile with -fPIC

One important piece I forgot to add -- I'm running "Hardened Gentoo GCC" 
which enables PIE by default [1] [2]. As such, this might explain why other 
are (presumably) not seeing this problem.

BTW, I cannot find my original submission on patchwork. Was that e-mail OK? 
I see it in the ML archive [3].

With kind regards,
Jan

[1] 
https://wiki.gentoo.org/wiki/Hardened/Toolchain#Automatic_generation_of_Position_Independent_Executables_.28PIEs.29
[2] 
https://wiki.gentoo.org/wiki/Hardened/Toolchain#Toolchain_modifications_for_automatic_PIEs
[3] http://lists.busybox.net/pipermail/buildroot/2017-April/189441.html

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Arnout Vandecappelle]

On 19-04-17 18:23, Jan Kundr?t wrote:
>> Without this patch, I cannot build the toolchain (both host-gcc-initial
>> and -final) on Gentoo's amd64 using GCC 4.9.3:
>>
>>   /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld:
>>   gcov.o: relocation R_X86_64_32 against `.rodata.str1.8' can not
>>   be used when making a shared object; recompile with -fPIC
> 
> One important piece I forgot to add -- I'm running "Hardened Gentoo GCC" which
> enables PIE by default [1] [2]. As such, this might explain why other are
> (presumably) not seeing this problem.

 Indeed. However, I wonder, won't you have a similar problem with other host
packages that try to build something without -fPIC?


 We don't like to accept patches where it is not clear what happens, i.e. how
this particular change fixes your problem...


> BTW, I cannot find my original submission on patchwork. Was that e-mail OK? I
> see it in the ML archive [3].

 I believe it's because you sent it base64-encoded, patchwork only likes
plaintext. You didn't use git send-email, did you?

 Regards,
 Arnout

> 
> With kind regards,
> Jan
> 
> [1]
> https://wiki.gentoo.org/wiki/Hardened/Toolchain#Automatic_generation_of_Position_Independent_Executables_.28PIEs.29
> 
> [2]
> https://wiki.gentoo.org/wiki/Hardened/Toolchain#Toolchain_modifications_for_automatic_PIEs
> 
> [3] http://lists.busybox.net/pipermail/buildroot/2017-April/189441.html
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Jan Kundrát]

On pond?l? 24. dubna 2017 0:06:30 CEST, Arnout Vandecappelle wrote:
>  Indeed. However, I wonder, won't you have a similar problem with other host
> packages that try to build something without -fPIC?

Here's a list of host packages that I built with no additional patches:

build/host-acl-2.2.52
build/host-attr-2.4.47
build/host-autoconf-2.69
build/host-automake-1.15
build/host-binutils-2.28
build/host-bison-3.0.4
build/host-dosfstools-4.0
build/host-expat-2.2.0
build/host-e2fsprogs-1.43.4
build/host-fakeroot-1.20.2
build/host-flex-2.5.37
build/host-gawk-4.1.4
build/host-gcc-final-6.3.0
build/host-gcc-initial-6.3.0
build/host-genext2fs-1.4.1
build/host-genimage-9
build/host-gettext-0.19.8.1
build/host-gmp-6.1.2
build/host-gperf-3.0.4
build/host-intltool-0.51.0
build/host-isl-0.14.1
build/host-kmod-24
build/host-libcap-2.25
build/host-libconfuse-3.0
build/host-libtool-2.4.6
build/host-libxml-parser-perl-2.44
build/host-libxml2-2.9.4
build/host-makedevs
build/host-mke2img
build/host-mkpasswd
build/host-mpc-1.0.3
build/host-mpfr-3.1.5
build/host-mtools-4.0.18
build/host-m4-1.4.18
build/host-ncurses-6.0
build/host-pkgconf-0.9.12
build/host-protobuf-c-v1.1.1
build/host-protobuf-v3.0.0
build/host-swig-3.0.10

When I try to rebuild some of them (`make host-$foo-rebuild`), I don't see 
any actual compilation for those that I tried (acl, kmod, swig). It seems 
to me that (except for the toolchain) the compilation is only performed 
when rebuilding the package for the target, and in that case, the newly 
built toolchain which has been previously built by Buildroot gets invoked. 
I.e., the host GCC doesn't get triggered after a toolchain has been built, 
as far as I can see now.

Am I missing something? Is there a host package that I should try to get 
built/rebuilt?

>> BTW, I cannot find my original submission on patchwork. Was 
>> that e-mail OK? I
>> see it in the ML archive [3].
>
>  I believe it's because you sent it base64-encoded, patchwork only likes
> plaintext. You didn't use git send-email, did you?

The copy of the original patch submission that I have in my sent folder 
doesn't appear to be base64-encoded -- it was a result of a `git 
format-patch` with no additional transformation after all.

However, I noticed that the outgoing e-mail was missing a Message-ID 
header, and it seems legit to reject these messages for various reasons.

With kind regards,
Jan

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Arnout Vandecappelle]

On 24-04-17 13:19, Jan Kundr?t wrote:
> On pond?l? 24. dubna 2017 0:06:30 CEST, Arnout Vandecappelle wrote:
>>  Indeed. However, I wonder, won't you have a similar problem with other host
>> packages that try to build something without -fPIC?
> 
> Here's a list of host packages that I built with no additional patches:
> 
[snip an impressive list of packages]
> 
> When I try to rebuild some of them (`make host-$foo-rebuild`), I don't see any
> actual compilation for those that I tried (acl, kmod, swig).

 Indeed, foo-rebuild will just call 'make' again, but since nothing changed it
will not actually compile anything. If you want to do a clean rebuild you have
to do 'make foo-dirclean foo'


> It seems to me that
> (except for the toolchain) the compilation is only performed when rebuilding the
> package for the target, 

 Nope, target behaves the same. Even if you changed the toolchain configuration,
'make foo-rebuild' will not rebuild much... foo-rebuild is meant mainly for
OVERRIDE_SRCDIR use cases.

> and in that case, the newly built toolchain which has
> been previously built by Buildroot gets invoked. I.e., the host GCC doesn't get
> triggered after a toolchain has been built, as far as I can see now.
> 
> Am I missing something? Is there a host package that I should try to get
> built/rebuilt?

 No, if you managed to build all these host packages with the default-PIE host
compiler, then I guess it's OK.

> 
>>> BTW, I cannot find my original submission on patchwork. Was that e-mail OK? I
>>> see it in the ML archive [3].
>>
>>  I believe it's because you sent it base64-encoded, patchwork only likes
>> plaintext. You didn't use git send-email, did you?
> 
> The copy of the original patch submission that I have in my sent folder doesn't
> appear to be base64-encoded -- it was a result of a `git format-patch` with no
> additional transformation after all.

 The mail I received through the mailing list was base64-encoded.


> However, I noticed that the outgoing e-mail was missing a Message-ID header, and
> it seems legit to reject these messages for various reasons.

 That could indeed be the reason as well. Checking in patchwork sources... Yes
indeed, it checks for From, Subject and Message-Id and drops the mail if those
are not there.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Jan Kundrát]

On pond?l? 24. dubna 2017 22:21:28 CEST, Arnout Vandecappelle wrote:
> No, if you managed to build all these host packages with the 
> default-PIE host compiler, then I guess it's OK.

You're right. Indeed, my regular PIE-using compiler is used when building 
these host utilities. Sorry for this confusion on my side re `make 
foo-rebuild`.

Does that change your position on the original patch? Should I 
resend/reformat it to explicitly refer to the Gentoo Hardened compiler 
which is happy to use PIC/PIE? Or is that nonetheless something that does 
not belong to Buildroot in your opinion?

Cheers,
Jan

[Buildroot] [PATCH] gcc: Fix build failure related to -fPIC for x86_64 -> i686 builds

[Jan Kundrát]

Without this patch, I cannot build the toolchain (both host-gcc-initial
and -final) on Gentoo's amd64 using GCC 4.9.3:

  /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld:
  gcov.o: relocation R_X86_64_32 against `.rodata.str1.8' can not
  be used when making a shared object; recompile with -fPIC

According to the GCC mailing list, a similar problem [1] related to
libgccjit was fixed by passing --enable-host-shared. My failure doesn't
appear to have anything in common with libgccjit, but that configure
flag fixed my build as well.

I wonder if we actually need gcov in the first stage of a GCC build...

[1] https://gcc.gnu.org/ml/gcc-help/2016-03/msg00026.html

Signed-off-by: Jan Kundr?t <jan.kundrat@cesnet.cz>
---
 package/gcc/gcc.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index b52f945..1e760d0 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -92,6 +92,7 @@ HOST_GCC_COMMON_CONF_OPTS = \
 	--with-gnu-ld \
 	--disable-libssp \
 	--disable-multilib \
+	--enable-host-shared \
 	--with-gmp=$(HOST_DIR)/usr \
 	--with-mpc=$(HOST_DIR)/usr \
 	--with-mpfr=$(HOST_DIR)/usr \
-- 
2.10.2