I am trying to reconcile why make.bash accepts GOARCH, GOOS and other target variables when it also supports cross compiling to all supported architectures by default. I am compiling this for amd64/linux but will be using the compiler to cross-compile apps for arm/linux in an embedded context. Buildroot builds Go with the following command
cd /builddir/build/host-go-1.10.2/src &&
GOROOT_BOOTSTRAP=/builddir/host/lib/go-1.4.3
GOROOT_FINAL=/builddir/host/lib/go
GOROOT="/builddir/build/host-go-1.10.2"
GOBIN="/builddir/build/host-go-1.10.2/bin"
GOARCH=arm
GOARM=7
GOOS=linux
CC=/usr/bin/gcc
CXX=/usr/bin/g++
GO_ASSUME_CROSSCOMPILING=1
CC_FOR_TARGET="/builddir/host/bin/arm-linux-gnueabihf-gcc"
CXX_FOR_TARGET="/builddir/host/bin/arm-linux-gnueabihf-g++"
CGO_ENABLED=1
./make.bash
Which works and goes on to build other apps just fine. My question is why are these target variables relevant at this stage? Wouldn't that only be relevant to the applications being compiled with this program?
The Go compiler and linker are Go programs. make.bash needs to know which architecture and which operating system to build the Go toolchain for.
See Downloads - The Go Programming Language for examples of the different architectures and operating systems.
See Installing Go from source.
Related
What is the reason and how to solve it? Please..
cmd : CGO_ENABLED=1 GOOS=linux GOARCH=arm GOARM=7 go build
output:
# runtime/cgo
clang: error: argument unused during compilation: '-marm' [-Werror,-Wunused-command-line-argument]
OS: macOS Big Sur
Golang verson: go1.17 darwin/amd64
Read the fine manual:
When cross-compiling, you must specify a C cross-compiler for cgo to use. You can do this by setting the generic CC_FOR_TARGET or the more specific CC_FOR_${GOOS}_${GOARCH} (for example, CC_FOR_linux_arm) environment variable when building the toolchain using make.bash, or you can set the CC environment variable any time you run the go tool.
So you need to specify the cross-compiler for CGo, e.g. like so:
CC=arm-linux-gnueabihf-gcc CGO_ENABLED=1 GOOS=linux GOARCH=arm GOARM=7 go build
For C++ code also add CXX=arm-linux-gnueabihf-g++.
You'll need to have gcc-arm-linux-gnueabihf and libc6-dev-armhf-cross packages installed for the above to work (on Linux, don't know about Mac).
I need to build a shared library in Go. For this purpose, I used CGO and then built SO lib with options
go build -o libUtil.so -buildmode=c-shared main.go
Now, I need to do the same, but for ARM architecture. When I do not use CGO, I only do export GOARCH=arm
and this is enough to succeed. However, when I use CGO, I can not build SO library.
I suspect, that I need to install arm build tools, but I don`t know how to do that and how to configure my GO environment to use these tools. I hope, somebody might help me.
OS is Linux.
It may be different in you own *.nix system, but in common case your settings shoul de like below:
export CC=arm-linux-gnueabi-gcc //choose your arm compiler binary
export GOARCH=arm
export CGO_ENABLED=1
then you cab build:
go build -o yourLib.so -buildmode=c-shared main.go
I am trying to cross compile my clang/LLVM based ELLCC cross development tools project on a Mac. I am targeting ARM/Linux. The build fails while building FileCheck (or tbl-gen or any of the other build tools built during the cross-compile-build-tools step) because the build rules try to pass the --version-script option to the linker. There is a lot of configure magic going on and I can't seem to find the spell that says not to use --version-script on a Mac.
A little clarification of my problem. ELLCC builds fine on a Mac and creates executables that can be used to create ARM/Linux programs (or Mips/Linux, Microblaze/Linux, PowerPC/Linux, etc). The trouble I'm having is when I try to make ELLCC compile itself for the target.
clang/LLVM needs several tools that it supplies that need to run on the build host. Those tools are being compiled properly as Mac executables using the native Mac clang, but the link stage is mixed up and trying to use --version-script even though the Mac linker doesn't support it.
You practically had the magic flag (or spell) in your title. I think you might be looking for:
--disable-ld-version-script
There are also suggestions and considerations that deal with cross-compiling which can be found here (section Cross-Compiling a Self-Bootstrapping Tool might be of relevance).
It turns out that there is a problem with the rules used to cross build stuff. When I build for Linux on OS X, The variable HOST_OS is "Linux" in Makefile.rules. I had to add a Darwin conditional:
ifeq ($(HOST_OS), $(filter $(HOST_OS), DragonFly Linux NetBSD FreeBSD GNU/kFreeBSD GNU))
ifneq ($(shell uname -s),Darwin)
ifneq ($(ARCH), Mips)
LD.Flags += -Wl,--version-script=$(LLVM_SRC_ROOT)/autoconf/ExportMap.map
endif
endif
endif
endif
There probably should be a BUILD_OS vs. HOST_OS, or HOST_OS is set incorrectly here.
I build a cross compile toolchain on OSX with:
binutils-2.23.52
gcc-4.6.4
gcc-core-4.6.4
gcc-g++-4.6.4
gdb-7.6.1
gmp-4.3.2
mpc-1.0.1
mpfr-2.4.2
newlib-2.0.0
for the target EFM32 wich is a ARM Cortex-m3, so the gcc target is arm-none-eabi.
All compiled fine.
But making programs with this toolchain like blink.c don't actually run on the EFM32 board.
I checked the blink.bin I did with a binary created with a IAR commercial toolchain delivered in the demos from energymicro, also gcc based and the they look very different internally (as expected :).
So has my toolchain wrong libs/versions or is it simply a matter of gcc/ld/ar switches wrong and what would be the steps to systematicly analyse this?
Motorola provides a cross compiling toolchain for building Software for their Set Top Box VIP1710. You have to extract it to /usr/local/kreatel and there you have a tree of build tools:
./bin
./bin/mipsel-kreatel-linux-gnu-addr2line
./bin/mipsel-kreatel-linux-gnu-ar
./bin/mipsel-kreatel-linux-gnu-as
./bin/mipsel-kreatel-linux-gnu-c++
./bin/mipsel-kreatel-linux-gnu-c++filt
./bin/mipsel-kreatel-linux-gnu-cpp
./bin/mipsel-kreatel-linux-gnu-g++
./bin/mipsel-kreatel-linux-gnu-gcc
...
./include
./lib
Now how do I make those configure scripts using my cross-compiling tools instead of my systems' gcc?
the --host parameter to configure, like this
./configure --host=arm-9tdmi-linux-gnu
where arm-9tdmi-linux-gnu is the identfication of the target system in my case - you can have multiple targets in one crosstool installation btw.