[opensuse-arm] icecream for armv7l broken
Howdy, After a bit of debugging, I was able to isolate some build failures we have, like the following:
rpm: error while loading shared libraries: /lib/libselinux.so.1: unexpected reloc type 0x03
At least one major difference I can see in compiling between an icecream gcc invocation and a native gcc invocation is the following:
toonie:/home/abuild/rpmbuild/BUILD/libselinux-2.1.9/src> gcc -O2 -g -march=armv7-a -mfloat-abi=hard -mthumb -mabi=aapcs-linux -I../include -I/usr/include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -DSHARED -c -o enabled.lo enabled.c enabled.c: In function 'is_selinux_enabled': enabled.c:34:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] enabled.c: In function 'is_selinux_mls_enabled': enabled.c:69:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes] toonie:/home/abuild/rpmbuild/BUILD/libselinux-2.1.9/src> /usr/bin/gcc -O2 -g -march=armv7-a -mfloat-abi=hard -mthumb -mabi=aapcs-linux -I../include -I/usr/include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -DSHARED -c -o enabled.lo enabled.c
So for some reason gcc doesn't seem to believe our linker knows what hidden attributes are. Weird, eh? So let's check out the gcc armv7l icecream build log:
checking for armv7l-suse-linux-gnueabi-as... no checking what assembler to use... checking for armv7l-suse-linux-gnueabi-ld... no basename: missing operand Try 'basename --help' for more information. checking whether we are using gold... no checking what linker to use... checking for armv7l-suse-linux-gnueabi-nm... no checking what nm to use... checking for armv7l-suse-linux-gnueabi-objdump... no checking what objdump to use... not found checking for readelf... /usr/bin/readelf checking what readelf to use... /usr/bin/readelf checking assembler flags... checking assembler for .balign and .p2align... no checking assembler for .p2align with maximum skip... no checking assembler for .literal16... no checking assembler for working .subsection -1... no checking assembler for .weak... no checking assembler for .weakref... no checking assembler for .nsubspa comdat... no checking assembler for .hidden... no checking linker for .hidden support... no checking linker read-only and read-write section mixing... unknown
Huh? It really doesn't know what its linker should be, so it isn't able to figure out its features, thus disables them internally. But why? Well, let's see what the s390 build has to say:
checking what assembler to use... /usr/s390x-suse-linux/bin/as checking whether we are using gold... no checking what linker to use... /usr/s390x-suse-linux/bin/ld checking what nm to use... /usr/s390x-suse-linux/bin/nm checking what objdump to use... /usr/s390x-suse-linux/bin/objdump checking for readelf... /usr/bin/readelf checking what readelf to use... /usr/bin/readelf checking assembler flags... checking assembler for .balign and .p2align... yes checking assembler for .p2align with maximum skip... yes checking assembler for .literal16... no checking assembler for working .subsection -1... yes checking assembler for .weak... yes checking assembler for .weakref... yes checking assembler for .nsubspa comdat... no checking assembler for .hidden... yes checking linker for .hidden support... yes checking linker read-only and read-write section mixing... read-write
Funny. The s390x target finds its cross binutils in /usr/s390x-suse-linux/. Why don't we find ours for armv7l then? Maybe it's because we don't have cross-armv7l-binutils that store something in /usr/armv7l-suse-linux/, but instead we have cross-arm-binutils that have their stuff in /usr/arm-suse-linux/? How does gcc's configure know where to search for the cross binutils? I'm fairly sure we're doing something pretty wrong there today :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.06.2012 19:17, Alexander Graf wrote:
How does gcc's configure know where to search for the cross binutils? I'm fairly sure we're doing something pretty wrong there today :)
OK, it's fixed in qemu_accel - I'll prepare a real update to the gcc package. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wed, 6 Jun 2012, Stephan Kulow wrote:
On 05.06.2012 19:17, Alexander Graf wrote:
How does gcc's configure know where to search for the cross binutils? I'm fairly sure we're doing something pretty wrong there today :)
OK, it's fixed in qemu_accel - I'll prepare a real update to the gcc package.
Ehm - --with-build-time-tools only changes the tools used for building gcc, not those used when executing the built gcc. So, not sure what the issue is at the end (but yes, the gcc build itself is broken right now). So, sth like Index: gcc.spec.in =================================================================== --- gcc.spec.in (revision 83585c777b3bd7264c2888d69f8c954c) +++ gcc.spec.in (working copy) @@ -1100,6 +1100,9 @@ %if 0%{?gcc_icecream:1} --with-sysroot=/ \ --enable-linux-futex \ +%endif +%if 0%{?binutils_target:1} + --with-build-time-tools=/usr/%{binutils_target}-suse-linux/bin \ %endif %if 0%{?build_static:1} --disable-shared \ should fix it. I'll include that in the update I am preparing if you can confirm it works for you (checked into devel:gcc for now, there are crosses building for arm there). Richard. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.06.2012 10:55, Richard Guenther wrote:
On Wed, 6 Jun 2012, Stephan Kulow wrote:
On 05.06.2012 19:17, Alexander Graf wrote:
How does gcc's configure know where to search for the cross binutils? I'm fairly sure we're doing something pretty wrong there today :)
OK, it's fixed in qemu_accel - I'll prepare a real update to the gcc package.
Ehm - --with-build-time-tools only changes the tools used for building gcc, not those used when executing the built gcc.
That's ok. The problem is that gcc checks during build how to call the gcc when invoked. In the environment we call the compiler, there is only one tool chain and cross-* picks the right ones. But the linker is the native one, so they need to match. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Richard Guenther -
Stephan Kulow