Fix cgo toolchain path error when on target platform. #18
Conversation
The path to the gcc and g++ compilers had the yocto build system's paths rather than a target system path baked into the tools. This caused broken builds for native code on the target device. The compile task for the recipe added the package's workspace to PATH and used explicit paths to the compilers to the batch files that wrapped access to the tools.
|
I see. I need to revisit this. The intention of that (ugly) wrapper is to be able to cross-build CGo packages, I never intended for this to be used on the target. Am I misunderstanding you? |
I guess then it's a bonus feature! :) For some reason, when Go is built, the tools have baked in cgo paths from where the tool build process was performed (it's known behavior.) Your clever redirect was the perfect place to hook a fix in. The patch essentially encourages that process only put the tool name, sans path, in the tool executables so the name can be easily found in the path on the target system. With this I can build a Golang environment that can be used on the target system. In my case it's an IMX6 Quadcore. It's nice for lab or field dev work for instance. Cross building using bitbake works as well. -Dale |
|
I need to update this to take care of the conflicts :-P |
2 participants
The path to the gcc and g++ compilers had the yocto build system's
paths rather than a target system path baked into the tools.
This caused broken builds for native code on the target device.
The compile task for the recipe added the package's workspace to
PATH and used explicit paths to the compilers in the batch files
that wrapped access to the tools.