[meta-virtualization] [PATCH] go-cross: Fix host contamination for x86_64 host to x86_64 target

Jason Wessel jason.wessel at windriver.com
Tue Sep 20 10:06:43 PDT 2016

On 09/20/2016 09:57 AM, Mark Asselstine wrote:
> On Mon, Sep 19, 2016 at 3:33 PM, Jason Wessel
> <jason.wessel at windriver.com> wrote:
>> The go-cross package is explicitly for compiling target libraries on
>> the host system.  When the target architecture matches the host
>> architecture it will actually use the host's linker and compiler
>> however which can result in the generation of the cgo.a library having
>> linker symbols which might not work properly when compiling other
>> packages.
>> A typical error looks like this when building consul-migrate:
>> /opt/build-intel-x86/tmp/sysroots/x86_64-linux/usr/lib/x86_64-linux/go/pkg/tool/linux_amd64/link: running x86_64-yocto-linux-gcc failed: exit status 1
>> /opt/build-intel-x86/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-yocto-linux/gcc/x86_64-yocto-linux/5.2.0/ld: /opt/build-intel-x86/tmp/work/core2-64-yocto-linux/consul-migrate/git-r0/build-tmp/go-link-956548052/000002.o: unrecognized relocation (0x2a) in section `.text'
>> /opt/build-intel-x86/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-yocto-linux/gcc/x86_64-yocto-linux/5.2.0/ld: final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>> The fix is to use the make.bash --target-only option to properly build
>> the libraries with the target toolchain.
>> Signed-off-by: Jason Wessel <jason.wessel at windriver.com>
>> ---
>>   recipes-devtools/go-cross/go-cross.inc | 4 ++++
>>   1 file changed, 4 insertions(+)
>> diff --git a/recipes-devtools/go-cross/go-cross.inc b/recipes-devtools/go-cross/go-cross.inc
>> index 613e9c7..c1577e3 100644
>> --- a/recipes-devtools/go-cross/go-cross.inc
>> +++ b/recipes-devtools/go-cross/go-cross.inc
>> @@ -26,6 +26,10 @@ do_compile() {
>>       cd src
>>       ./make.bash --host-only
>> +    if [ "${GOARCH}" = "amd64" -a "${BUILD_ARCH}" = "x86_64" ] ; then
>> +        # Ensure cgo.a is built with the target toolchain
>> +        GO_FLAGS="-a" ./make.bash --target-only
>> +    fi
> Since this is a "cross" tool it really does have a foot in both camps.
> ie. it is not clearly something which is purely setup to run/exist on
> the build host, nor is it something being built to be installed and
> run on the target. It is rather something which is built to run on the
> host but has ties with the -native sysroot (for example some of the
> dependencies might exist not as part of the host system but only in
> the -native sysroot, and to a certain extent it might expect the
> sysroot has similarities to the target rootfs).
>  From what I can tell I believe that go-cross is being linked using the
> host's linker and link flags which allows it to build, but when it
> goes to be used as a crosstool it is attempting to use aspects of the
> -native sysroot and due to the mismatch in binutils versions and
> similar the result is the build failures we are seeing in
> consul-migrate. Your workaround forces the build and linking to be
> done as if we were building for the target, since if statement
> restricts this to when the GOARCH and BUILD_ARCH match, this allows it
> to function on the host as a crosstool. This is clever but could have
> side effects since it might use dynamic libs and tools not in the
> -native sysroot but actually in the -target sysroot, will this survive
> rmwork or when 'tmp' is wiped out and things are built from sstate?
> I have found another possible solution which doesn't have the possible
> side effects mentioned above.
> -      ./make.bash --host-only
> +     GO_EXTLINK_ENABLED="0" ./make.bash --host-only
> According to the make.bash text this will force usage of the internal
> linker and it appears that by using this instead of the host's linker
> the environment we have setup for when we do_compile allows the
> -native sysroot to be taken into account and the result is a proper
> mix of host vs. -native sysroot bindings. Ideally I would like to use
> the host LD and just pass the proper flags to allow a similar result
> to using the internal linker, but I have not had any success.
> Thoughts?

I believe we need to go even a step further and build out the ARM binaries when the host is X86_64.   What I found upon further investigation is that the sysroot is changed outside of a sysroot packaging rule.  The go-cross tool is the offender.  The first ARM package which needs go-cross will build and populate cgo.a into the sysroot directly.   This poses a problem with parallel package builds as well as controlling updates to the sysroot.

I created a v2 patch to address this secondary problem.


More information about the meta-virtualization mailing list