I try to compile a go program on my Linux desktop (Linux desktop 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux), go version go version go1.8.3 linux/amd64 to arm:
$ GOPATH=/home/xrfang/git/hermes/ GOARM=7 GOARCH=arm go build .
the executable is generated, but seems NOT ARMv7:
$ file hermes
hermes: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
It shows EABI5. How can I cross-compile to ARMv7? Is there anything missing on my Linux Desktop so that the cross-compile fallback to a lower ARM version?
Thanks.
I believe, it is not ARMv5. I was trying to do the same on MAC OS and 'file' command on Mac is saying v7, but the 'file' command on Linux don't. However, I do know that v7 has some good improvements and may boost the performance of your program.
But, that is out of scope of this question and you may need to dig deeper into what you're doing and why a performance improvement is expected.
All I can say is, it is compiled for v7.
Related
I know go doesn't have multi architecture support in their binary. I am cross compiling a go dbus application and the cross compiled binary is still running on my host computer. I am running debian testing. Can this be a coming up feature or so?
$ go version
go version go1.11.5 linux/amd64
$:golang-godbus$ go build
$:golang-godbus$ file golang-godbus
golang-godbus: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=rtpT-vZ73aaq-OWCmm29/BqcyUmwm1ybWYgaZEdN7/Ll0SYgA2TzwyWDpTcfmI/fZ-z5lzvDaDWOFC4XHw8, not stripped
$:golang-godbus$ GOOS=linux GOARCH=arm GOARM=7 go build
$:golang-godbus$ file golang-godbus
golang-godbus: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=GgidUi9KoU1Ku-VzGDlJ/Lb9Rrl0prlg6BfmlJhvv/Lt1JZ03bbrg1XFqGdA1Q/VNKiL2-y3UnN_7F4P8IP, not stripped
$:golang-godbus$ ./golang-godbus
Currently owned names on the session bus:
org.freedesktop.DBus
:1.15319
:1.7
org.freedesktop.login1
org.freedesktop.timesync1
:1.10601
:1.10603
org.freedesktop.systemd1
:1.11095
:1.10605
org.freedesktop.PolicyKit1
org.freedesktop.Avahi
org.freedesktop.ModemManager1
org.freedesktop.NetworkManager
:1.11
:1.241
org.freedesktop.UDisks2
org.freedesktop.network1
:1.7704
:1.233
fi.epitest.hostap.WPASupplicant
:1.4
fi.w1.wpa_supplicant1
:1.23524
:1.19
:1.6
I have a router Asus RT-AC68R with 32GB memory pen mounted to /opt. On it is installed entware including all the tools to build programs natively on the platform ARMv7. Router use TomatoUSB firmware.
I wrote a program to support the module based on the chip FT245 connected via USB to the router. The program compiled on Linux x86_64 and it works correctly on a standard Linux PC. It was - of course - necessary installing library supplied by the manufacturer (FTDI). The manufacturer provides these libraries for various platforms, including the ARMv7 versions soft and hard float. On router I installed library hard float.
These libraries are HERE
So I'm trying to compile the program, prior to the installation of the pen FTDI libraries, according to the documentation. Unfortunately, after starting the program an library error occurs.
Below the way I compile this program (named arco) and the result of running this program on my ARMv7 based router.
root#asus:/opt# gcc -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/usr/local/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -l ftd2xx arco.c -o arco
root#asus:/opt# ./arco
./arco: error while loading shared libraries: /opt/usr/local/lib/libftd2xx.so: internal error
Additional information about my dev environment:
root#asus:/opt/FTDI# echo $PATH
/opt/bin:/opt/sbin:/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/root:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:
root#asus:/opt/FTDI# echo $LD_LIBRARY_PATH
/lib:/usr/lib:/usr/local/lib:/opt/lib:/opt/usr/lib:/opt/include
root#asus:/opt/FTDI# opkg list-installed|grep gcc
gcc - 5.4.0-1
libgcc - 5.4.0-5
root#asus:/opt# uname -a
Linux asus 2.6.36.4brcmarm #5 SMP PREEMPT Tue Aug 16 22:49:47 CEST 2016 armv7l GNU/Linux
I am fairly new when it comes to platform ARMv7 but maybe there is something in compilation options I use:
-mfloat-abi=soft
a library installed is hard-float. I do not know if this could be the reason so expect council colleagues.
Thank you in advance for your answers!
I have an ARM machine that runs Linux (BusyBox).
# uname -a
# Linux XXXXXXXX 2.6.28 #1 PREEMPT Fri Sep 26 22:47:38 UTC 2014 armv5tel GNU/Linux
I've cross-compiled a simple program on my Ubuntu 32-bit desktop:
./configure --host=arm-linux-gnueabi LDFLAGS="-static"
make
But when I try to run it on the ARM machine, it gives me Segmentation Fault error.
Program is super simple:
#include <stdio.h>
int main()
{
printf("Hello, World!");
return 0;
}
Here are a few things I've already tried/checked:
I've checked md5 hashes on both machines to eliminate the possibility that something went wrong at the time of copying an executable over the network
Stripped the executable with arm-linux-gnueabi-strip. I was comparing my executable with another executable that was already in the target machine with file:
# file my_program
# my_program: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.31, BuildID[sha1]=0x4b1f2773e54b141d5157b86f0f10438a372625c9, stripped
# file their_program
# their_program: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), statically linked, stripped
What am I doing wrong?
Apparently my cross-compile toolchain was not the right one.
I ended up using crosstool-ng. Btw it's very simple to use and a great tool, all you have to do is to choose the right toolchain for your device.
I have built an arm-unknown-linux-uclibcgnueabi toolchain with crosstool-ng, which solved my problem.
I am trying to compile Linux kernel with -O0 flag for debugging (to disable optimization like inline functions support in GCC otherwise I am getting random jumps/holes in stack-frames).
I did some googling and found few related posts but they were not very encouraging for this idea. Some of the said its not possible, others suggested that it may not be very useful. I also saw few patches (for ARM) floating in KGDB mailing list. Now I am little confused. Just wondering if anyone tried compiling latest kernel with -O0 flag.
My Linux version: Linux 3.0.1-rt11-svn9237 #2 PREEMPT RT Fri Dec 21 09:58:42 IST 2012 armv7l GNU/Linux
My GCC version: arm-none-linux-gnueabi-gcc-4.3.3
I have trouble understanding the gcc compiler provided by OSX 10.6 snow leopard, mainly because of my lack of experience with 64 bits environments.
$ cat >foo.c
main() {}
$ gcc foo.c -o foo
$ file foo
foo: Mach-O 64-bit executable x86_64
$ lipo -detailed_info foo
input file foo is not a fat file
Non-fat file: foo is architecture: x86_64
However, my architecture is seen as an intel i386 type (I have one of the latest Intel Core2 duo MacBook)
$ arch
i386
and the compiler targets i686-apple-darwin10
$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Of course, if I compile 32 bits I get a 32 bit executable.
$ gcc -m32 foo.c -o foo
$ file foo
foo: Mach-O executable i386
but I don't get the big picture. The default setup for the compiler is to produce x86_64 executables, even if I have arch saying I have a 32 bit machine (why? Core2 is 64); even if (I guess) I am running a 32 bit kernel; even if I have a compiler targeting the i686-apple-darwin platform. Why? How can they run ? Should I compile 64 or 32 ?
This question is due to my attempt to compile gcc 4.2.3 on the mac, but I am having a bunch of issues with gmp, mpfr and libiberty getting (in some cases) compiled for x86_64. Should I compile everything x86_64 ? If so, what's the target (not i686-apple-darwin10 I guess)?
Thanks for the help
The default compiler on Snow Leopard is gcc4.2, and its default architecture is x86_64. The typical way to build Mac software is to build multiple architectures in separate passes, then use lipo to combine the results. (lipo only compiles single-arch files into a multiple-arch file, or strips archs out of a multi-arch file. It has no utility on single-arch files, as you discovered.)
The bitness of the compiler has nothing to do with anything. You can build 32-bit binaries with a 64-bit compiler, and vice versa. (What you think is the "target" of the compiler is actually its executable, which is different.)
The bitness of the kernel has nothing to do with anything. You can build and run 64-bit binaries when booted on a 32-bit kernel, and vice versa.
What matters is when you link, whether you have the appropriate architectures for linking. You can't link 32-bit builds against 64-bit binaries or vice versa. So the important thing is to see what the architectures of your link libraries are, make sure they're coherent, then build your binary of the same architecture so you can link against the libraries you have.
i686-apple-darwin10.0.0 contains an x86_64 folder which is not understood by most versions of autotools. In other words, I'd say that the gcc compiler is unfortunately nothing short of a joke on Snow Leopard. Why you would bundle 32-bit and 64-bit libraries into i686-apple-darwin10.0.0 is beyond me.
$ ls /usr/lib/gcc
i686-apple-darwin10 powerpc-apple-darwin10
You need to change all your autotools configure files to handle looking in *86-darwin directories and then looking for 64-bit libraries I'd imagine.
As with your system, my mac mini says its i386 even though its obviously using a 64-bit platform, again another mistake since its distributed with 64-bit hardware.
$arch
i386
Apple toolchains support multiple architectures. If you want to create a fat binary that contains x86 and x86_64 code, then you have to pass the parameters -arch i386 -arch x86_64 to gcc. The compiler will compile your code twice for both platforms in one go.
Adding -arch i386 -arch x86_64 to CFLAGS may allow you to compile gmp, mpfr, and whatnot for multiple archs in one go. Building libusb that way worked for me.
This answer is wrong, but see comments below
The real question is... how did you get a 32-bit version of OSX? I wasn't aware that Snow Leopard had a 32-bit version, as all of Apple's Intel chips are Core 2 or Xeon, which support the x86_64 architecture.
Oh, and Snow Leopard only works on Intel chips.
Edit: Apparently Snow Leopard starts in 32-bit mode.