I built my project which has protobuf as a dependency in arm cpu and intel cpu(cross compile arm) both.
In arm pc doesn't have problem to build, but in the crosscompile environment it has syntax error.
../usr/bin/protoc: Syntax error: ")" unexpected
In the proto file, it doesn't have any "(" or ")" characters.
Could I build a project using a dependency package which is compiled by the cross compiler?
This kind of cryptic error message is often caused by an attempt to execute a program compiled for another architecture.
The build process does provide a protoc executable, but if you are cross-compiling, is will be build for your target architecture, not the x86_64 one.
Since the build process will at one point attempt using the protoc executable it produced for its own purpose, it will fail executing it on your x86_64system because of the architecture mismatch.
You can check by executing the command file ../usr/bin/protoc. You should ideally see ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV) in the output, but should see ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV) or an AArch64 equivalent in the case I would be right.
When cross-compiling Protocol buffer, you need to make sure you have already built/installed protoc for x86_64 first, then use the following option when configuring for cross-compiling:
./configure --with-protoc=protoc
You will have to replace protoc by the location of the x86_64 protoc version in the case it would not be in your path.
See the Note for cross-compiling section of the Protocol Buffer documentation.
Related
I have installed Debian on qemu 64-bit ARM (followed this tutorial)
uname -a
Linux test 4.9.0-7-arm64 #1 SMP Debian 4.9.110-1 (2018-07-05) aarch64 GNU/Linux
and I am trying to run 32 bit elf files on it, but some work some don't:
bash: ./file_2: cannot execute binary file: Exec format error
running file command on the file that runs, I get:
file_1: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, not stripped
and the one that does not run:
file_2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically
linked, stripped
and both work on 32bit system(armv7l)
the only difference is that SYSV/ARM version.
is there any work around without recompiling the kernel?(read this post)
As the linked post suggests, this requires CONFIG_COMPAT to be enabled in the kernel. On the other hand I would be surprised if your kernel didn't have it -- the Debian 4.9.0-4 kernel I have from doing that tutorial does set CONFIG_COMPAT. You can check whether your kernel has it enabled by looking at the config file for it which will be in /boot/ in the guest. If it's missing then you need a new kernel, and nothing else will help.
However in your case you do have CONFIG_COMPAT, and some executables work. The difference between the ones that work and the ones that don't is that the working ones are EABI, and the non-working ones are OABI. OABI is an old and obsolete ABI for 32-bit Arm Linux binaries (the "O" stands for "old", and it's been a bad choice for a decade or so...) and it is not supported by the 64-bit kernel's CONFIG_COMPAT. You'll need to rebuild those binaries from source as EABI binaries if you want to run them under a 64-bit kernel.
I'm interested in compiling the sourceforge project https://svn.code.sf.net/p/archopen/code/ArchOpen/trunk/, and more especifically the app AOnes, which is a NES emulator for Archos Gmini 400 (Inactive old project)
Analyzing the source code, I saw that the Gmini400 is an arm7tdmi device, no MMU and the toolchain used to compile was a buildroot one named arm-linux-nofpu.
I supposed (according to the buildroot-2009-02 menuconfig) that no-fpu means soft floating point, so i tried to build such a toolchain.
I build a toolchain with buildroot-2013-02 (both year 2009 and 2010 don't work for me) with the following options:
arm7tdmi
no MMU
Software Floating Point
Enable elf2flt support (i saw there were such a reference in the
Makefile of ArchOpen)
I let the other options as they were and made the build.
I made a checkout of ArchOpen, launch the configuration script to choose Gmini4XX as the target (and not Gmini 402 chich is quite different), selected to defaut.rules and edit the resulting Makefile.conf to adapt the tools paths and names (as my generated toolchain name is different)
First error:
[thread.o]
{standard input}: Assembler messages:
{standard input}:1236: Error: Rn must not overlap other operand -- swpb r0,r3,[r0]
Well, this code is supposed to be working, but i opened thread.h and corrected the source to pass through (adding a "&")
Second error:
undefined reference to __aeabi_idivmod and undefined reference to __aeabi_ldivmod
As google says, it seems to be a -lgcc missing problem.
I edited the wav folder makefile to add -lgcc and specified -L/lib_folder_of_my_toolchain_containing_libgcc.a
Third error:
in gcc/config/arm/lib1funcs.asm : multiple definition of __divsi3
in gcc/config/arm/lib1funcs.asm : undefined reference to raise
in libgcc.a (some .o inside) : undefined reference to __aeabi_unwind_cpp_pr0
I've no idea to solve this...
Does anyone have an idea? Does anyone can help me to get a working arm7 toolchain compatible with this archopen code?
Thanks!
Well, in this particular case, back to 2005 was a good solution...
With a ubuntu 5.04, buildroot has been built with the defaut generic ARM (little endian) configuration, except for the following options:
GCC 3.3.5
No use the daily uClibc snapshot
The processor has no MMU
No support large file
Use softfloat by default
No install busybox (as I only wanted the toolchain)
No create an Ext2 filesystem (same reason than above)
The build fail just after having compiled the last GCC phase. At this point, add the buildroot/build_arm_nofpu/staging_dir/bin in the PATH env. variable, download the libfloat source (libfloat-990616.orig.tar.bz2) tarball, edit the Makefile changing gcc, ld and as repectively by arm-linux-uclibc-gcc, arm-linux-uclibc-ld and arm-linux-uclibc-as and build libfloat (make clean & make). Copy libfloat.a into buildroot/build_arm_nofpu/staging_dir/lib and run the buildroot make again (without cleaning). The build should end successfully. With this toolchain, mediOS will compile without any warning.
I am trying to build a gcc cross compiler. I understand that before compiling the cross compiler I need to have the target binutils built already. why the building of the compiler need the target binutils ? the compiler alone only takes high level code and turn it to the assembly that I defined it in the compiler sources. so why do I need the target bintools for compiling the cross compiler ? It is written in all of the cross compiler documentation that I need them to be build before compiling the cross compiler. (e.g. http://wiki.osdev.org/Building_GCC and http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html).
GCC needs an assembler to transform the assembly it generates into object files (machine code), and a linker to link object files together to produce executables and shared libraries. It also needs an archiver to produce static libraries/archives.
Those three are usually provided by the binutils package (among other useful tools): the GNU assembler as, linker ld and the ar archiver.
Your key question seems to be:
why the building of the compiler need the target binutils ?
As described in Building a cross compiler, part of the build process for a GNU cross-compiler is to build runtime libraries for the target using the newly-compiled cross-compiler. So the binutils for the target need to be present for that step to succeed.
It may be possible to build the cross-compiler first, using empty files for the subset of binutils components that gcc needs - such as as and ld and ar and ranlib - then build and install the target binutils components into the proper locations, then build the target runtime libraries.
But it would be less error-prone to do things the following way (and the documentation recommends this): build binutils for the target first, place the specified executables in gcc's source tree, then build the cross-compiler.
The binutils (binary utilities) provide low-level handling of
binary files, such as linking, assembling, and parsing ELF files. The GCC
compiler depends on these tools to create an executable, because it generates
object files that binutils assemble into an executable image.
ELF is the format that Linux uses for binary executable
files. The GCC compiler relies on binutils to provide much of the platform-specific functionality.
Here your are cross-compiling for some other architecture not for x86. So resulting binutils are platform-specific
while configuring has to give --host!=target. i.e --host=i686-pc-linux-gnu
where --target=arm-none-linux-gnueabi.
So resulting executable are not same which host already having binutils.
addition
the basic things needs to be known.
The build machine, where the toolchain is built.
The host machine, where the toolchain will be executed.
The target machine, where the binaries created by the
toolchain are executed.
So binutils will be having tools to generate and manipulate binaries
for a given CPU architecture. Not for the one host is using
I cross compiled a program on Ubuntu 12.04 running on x86 using gcc-arm-linux-gnueabi and binutils-arm-linux-gnueabi and compiling with arm-linux-gnueabi-gcc instead of gcc with my target architecture being ARM. It compiles fine with no errors or warnings.
When I try to run it on the ARM machine (Pandaboard - also running Ubuntu 12.04) I get:
bash: ./sttyl: No such file or directory
I know the file is there and it has the proper permissions:
-rwxrwxr-x 1 haziz haziz 8.5K Feb 10 10:34 sttyl
The output of file sttyl is
sttyl: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31,BuildID[sha1]=0x6d504f7d84b93603122223a89e2b5960c840309f, not stripped
When I compile it natively on the Pandaboard it compiles and runs fine. This is the output of file sttyl on the natively compiled copy:
sttyl: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31,BuildID[sha1]=0x9897c785266c5b7cdf580e08091aba239db84ecf, not stripped
What am I doing wrong? Moreover if I had made a mistake in the cross compilation I would have expected the shell/kernel to tell me effectively that the executable is for the wrong architecture not that it does not exist!
It isn't telling you that ./sttyl doesn't exist.
It's telling you that it spawned a new process, which exited with error No such file or directory. No information is provided about which file or directory was missing.
For example, a shell script starting with #!/bin/specialsh could generate that error if the interpreter /bin/specialsh was missing, even though the script existed and was executable.
Try using strace to find out what call (and path) caused the error.
I'm trying to use GDB to debug (to find an annoying segfault). When I run:
gdb ./filename
from the command line, I get the following error:
This GDB was configured as "i686-pc-linux-
gnu"..."/path/exec": not in executable
format: File format not recognized
When I execute:
file /path/executable/
I get the following info:
ELF 64-bit LSB executable, AMD x86-64,
version 1 (SYSV), for GNU/Linux 2.4.0,
dynamically linked (uses shared libs), not stripped
I am using GDB 6.1, and the executable is compiled with gcc version 3.4.6.
I'm a little out of my water in terms of using gdb, but as far as I can tell it should be working in this instance. Any ideas what's going wrong?
The executable is 64-bit (x86-64) and the debugger is a 32 bit (i686-pc-linux) build. You may need to install a 64-bit (x86-64) version of the debugger.
I'm not sure if this is your problem, but I faced this situation very often. The executable in the build tree, build by make/automake is not a binary, but a script, so you cannot use gdb with it. Try to install the application and change the directory, because else gdb tries to debug the script.
The question refers to "./filename" and to "/path/executable". Are these the same file?
If you are doing a post-mortem analysis, you would run:
gdb executable-file core-file
If you are going to ignore the core file, you would run:
gdb executable-file
In both cases, 'executable-file' means a pathname to the binary you want to debug. Most usually, that is actually a simple filename in the current directory, since you have the source code from your debug build there.
On Solaris, a 64-bit build of GDB is supposed to be able to debug both 32-bit and 64-bit executables (though I've had some issues with recent versions of GDB). I'm not sure of the converse - that a 32-bit GDB can necessarily debug 64-bit executables.
What you need to be checking, is really the bfd library. The binary file descriptor library is what binutils / gdb uses to actually parse and handle binaries (ELF/a.out etc..).
You can see the current supported platforms via objdump;
# objdump -H
objdump: supported targets: elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot elf64-powerpc elf64-powerpcle elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
objdump: supported architectures: rs6000:6000 rs6000:rs1 rs6000:rsc rs6000:rs2 powerpc:common powerpc:common64 powerpc:603 powerpc:EC603e powerpc:604 powerpc:403 powerpc:601 powerpc:620 powerpc:630 powerpc:a35 powerpc:rs64ii powerpc:rs64iii powerpc:7400 powerpc:e500 powerpc:MPC8XX powerpc:750
The following PPC specific disassembler options are supported for use with
the -M switch:
booke|booke32|booke64 Disassemble the BookE instructions
e300 Disassemble the e300 instructions
e500|e500x2 Disassemble the e500 instructions
efs Disassemble the EFS instructions
power4 Disassemble the Power4 instructions
power5 Disassemble the Power5 instructions
power6 Disassemble the Power6 instructions
32 Do not disassemble 64-bit instructions
64 Allow disassembly of 64-bit instructions
It seems your GNU Debugger (gdb) doesn't support x86_64 architecture.
So try LLDB Debugger (lldb) which aims to replace it. It supports i386, x86-64 and ARM instruction sets.
It's available by default on BSD/OS X, on Linux install via: sudo apt-get install lldb (or use yum).
See: gdb to lldb command map page for more info.