I'm using an m1 pro macbook pro.
Up until now, I used intel macbook.
My program is written in c/c++ and the target is ubuntu x86_64.
I tried running ubuntu x86 docker (qemu) and it's super slow - to the point it's unusable.
I have linux ubuntu (arm) installed using parallels and would like to compile for x86 target instead of arm.
How do I do it?
On Ubuntu, I would suggest an apt install gcc-x86-64-linux-gnu g++-x86-64-linux-gnu, and then invoking the installed compiler with the x86-64-linux-gnu prefix (for gcc, x86-64-linux-gnu-gcc) to create x86_64 binaries.
Do note that if you target x86_64 you won't be able to run the programs you build natively, but you should be able to package the binaries created for execution on an x86_64 machine.
Install docker-desktop on your mac and run this docker container with the command:
docker container run --platform=linux/amd64 -it -p 6080:6080 -e WIDTH=1920 -e HEIGHT=1080 yoas1/xubuntu-desktop:1.0
Don't forget to create volume to the code directory.
In your browser go to: http://localhost:6080/vnc.html to access the xubuntu desktop
Image on Dockerhub
Related
I have one C++ binary which is running smoothly on local centos. Recently, I started learning docker and trying to run my C++ application on centos docker.
Firstly, I pulled centos:latest from docker hub and installed my C++ application on it and it ran successfully, without any issue. Now i installed docker on raspberry-pi and pulled centos again and tried to ran the same application on it but it gave me error.
bash : cannot execute binary file
Usually, this error comes when we try to run application on different architecture then the one they are built on. I checked cat etc/centos-release on raspberry-pi and result is CentOS Linux release 7.6.1810 (AltArch),where as result on local centos is CentOS Linux release 7.6.1810 (Core)
uname -a on both devices is as follows
raspberry-pi, centos docker Linux c475f349e7c2 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l armv7l armv7l GNU/Linux
centos, centos docker Linux a57f3fc2c1a6 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
EDIT:
Also, file myapplication
TTCHAIN: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.24, BuildID[sha1]=287b501c8206893f7819f215ee0033586212b143, with debug_info, not stripped
My question is how can i ran the same native application of centos, pulled from docker on raspberry-pi model 3.
Your application has been built for x86-64. Intel x86-64 binaries CAN NOT run on an ARM processor.
You have two paths to pursue:
If you don't have source code for the application, you will need an x86-64 emulator that will run on your Raspberry Pi. Considering the Pi's lesser capabilities and Intel's proclivity to sue anyone who creates an emulator for their processors, I doubt you'll find one that's publicly available.
If you have the source code for the application, you need to rebuild it as a Raspberry Pi executable. You seem to know that it was written in C++. GCC and other toolchains are available for the Raspberry Pi (most likely a "yum install gcc" on your Pi will grab the compiler and tools for you). Building the application should be extremely similar to building it for x86_64.
You could find a cross-compiler that would let you build for the Pi from your x86_64 box, but that can get complicated.
Could be that you are trying to run a 64-bit binary on a 32-bit processor, would need more information to know for sure though.
You can check by using the file command in the shell. You may have to re-compile on the original system with the -m32 flag to gcc.
Please do a "uname -a" on both devices and post the results.
Most likely the processor or library type doesn't match.
I presume (hope) you're not trying to run an x86-compiled app on a Pi. Although Docker is available for both processor types, Docker will not run x86 binaries on Pi or vice versa.
Actually, AltArch currently means one of the following architectures... ppc64, ppc64le, i386, armhfp (arm v7 32-bit), aarch64 (arm v8 64-bit). Core suggests the mainstream x86 and x86_64 builds of CentOS.
Yep, I bet that's what it is...you can't just transfer an x86 binary to a Raspbian and expect it to work. The application must be rebuilt for the platform.
After I installed gdbserver on my remote machine (Ubuntu 16.04.4 LTS), I tested the following c++ code by making a "cross-platform console application (linux)" project in Visual Studio 2017:
#include <cstdio>
int main()
{
printf("hello from testLinuxDebug!\n");
return 0;
}
I added the connection information (ip address, id, password) of my Ubuntu machine to connection manager and selected "gdbserver" for debugging mode.
Then I started debugging and got the following message:
Unable to start debugging. Unexpected GDB output from command
"-interpreter-exec console "target remote localhost63361"". Remote
connection closed.
Message after starting to debugging (Image captured from VS2017)
By the way, I got the following message from the Linux Console Window of debug menu of Visual Studio 2017:
Process /home/.../projects/testLinuxDebug/bin/x64/Debug/testLinuxDebug.out
created; pid = 29277 Listening on port 4444 Remote debugging from host
127.0.0.1 /build/gdb-9un5Xp/gdb-7.11.1/gdb/gdbserver/regcache.c:264: A problem > internal to GDBserver has been detected. Unknown register ymm0h requested
Message from Linux Console Window (Image captured from VS2017)
Could anybody help me with this problem?
I was having this exact same problem on my Ubuntu 16.04 machine.
I went through the source code on gdbserver, and it appears to be a problem with a processor register (ymm0h) which is only available to i386 processors.
The thing is, I don't know how to fix gdbserver to not use this register in particular, but you can solve the error by upgrading your gdb & gdbserver to version 8.3 on the Ubuntu machine. If my guess is correct, version 8.1 was the one that fixed this issue, but by default, Ubuntu 16.04 has version 7.11.1 for both gdb & gdbserver.
You can run these commands on the linux machine to do that:
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
./configure --prefix=/usr --with-system-readline
make
sudo make install
You may need to install some extra packages in order to compile the gdb:
sudo apt-get install libreadline6-dev texinfo
If you still have problems trying to install gdb, try this example from Linux from Scratch.
Good luck!
I encountered the same problem as you, although for me the issue was on Microsoft's Visual Studio Online platform - I couldn't use pwntools' gdb.debug/gdb.attach functionality (that relies on gdbserver) due to this very same error in VSOnline's docker environment.
Leaving this answer here for people who might encounter the same issues that I have.
The issue and the steps are pretty similar to what Canella described - the root of the problem is indeed the old GDB version in the environment (7.12 at the time of writing).
I've compiled my GDB with python3 bindings, and you might want to do that too if you're planning to use GEF or similar GDB extensions.
Here's how to do that in your VSOnline environment's terminal:
# I needed to get rid of the apt-provided gdb for it to work properly
sudo apt remove gdb
# VSOnline has a weird way of handling python versions
# you're better off installing python3 from apt, if it's not installed yet
sudo apt update
sudo apt install libreadline6-dev texinfo python3 python3-dev
wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3
mkdir build && cd build
../configure --prefix=/usr --with-system-readline --with-python=/usr/bin/python3
make
sudo make install
I am compiling an application using the gcc arm cross compiler(arm-eabi-g++). I want to execute the code on the jetson tk1 target. When I copy the executable and run it on the target. I get an error saying -bash: ./Proj: No such file or directory
Should I include any extra conditions while building, inorder to run it on the target?
Can anyone suggest any other cross compiler that works?
It might be differing of system architecture and program architecture.
Look for the architecture of TX1 with command
uname -p
From JetPack v2.2 Jetson TX1 can be installed with aarch64 or armhf architecture
Simpliest way to cross compile is to use arm-linux-gnueabihf-g++ for armhf and aarch64-linux-gnu-g++ for aarch64. You can run armhf programs on aarch64 but you need to install armhf versions of all necessary libraries like libc or libstdc++:
sudo apt-get install libc6-dev:armhf
Are there specific steps I can take to build the Xuggle Xuggler source code from Windows 32-bit, Windows 64-bit, Linux 32-bit, and Linux 64-bit? I've tried multiple times on multiple systems and keep getting lots of different errors.
Update
I spent several days trying to get Xuggle Xuggler to compile (and
cross-compile). I successfully tackled compiling both the original GPL
version of the code and an LGPL version. I thought I'd post an
answer to my own question on Stack Overflow to share my knowledge.
Update on Raspberry Pi
I was also able to build and run Xuggler on the Raspberry Pi following these same basic instructions below. I just used
my LGPL version of the code that I maintain on Github, and made modifications for the Pi. I can use the compiled JAR file and binaries on my Radxa Rock (another ARM device) too. If you're interested
in building on the Pi, you can use my pi branch:
https://github.com/e-d/xuggle-xuggler
If you are lazy and just want the precompiled .jar files for the Pi/ARM:
GPL Version (supports H.264)
LGPL Version (no H.264 support)
Here is a formatted version of my answer in a published Google Document.
For completeness (and in case the link goes dead one day), here is less-nicely-formatted text:
Building Xuggle Xuggler (GPL and LGPL Licensed Versions)
[Linux 32-bit, Linux 64-bit, Windows 32-bit, Windows 64-bit]
To build the Xuggle Xuggler library, you will need two Linux virtual machines running Ubuntu 11.10 (32-bit and 64-bit operating systems). A 32-bit version of the OS is required to build Linux 32-bit, cross compiling Windows 32-bit, and cross compiling Windows 64-bit binaries. A 64-bit version of the OS is required to build Linux 64-bit binaries.
Using VirtualBox, I created the two virtual machines discussed above with the ubuntu-11.10-server-i386.iso and ubuntu-11.10-server-amd64.iso disk images. These are headless server versions of Ubuntu. After installation of the OS, follow these steps to build Xuggler (you are welcome to try different dependency versions and not use the root user, but this is what I did to build successfully):
Change to root user:
sudo su
Just use root’s home directory:
cd /root
Update apt-get to use specific repository:
apt-get install python-software-properties
add-apt-repository ppa:ferramroberto/java
apt-get update
Install Java:
apt-get install sun-java6-jdk sun-java6-plugin
Verify the HotSpot Java 6 JVM is the default java:
java -version
If the incorrect version of Java appears, configure the default by running:
update-alternatives --config java
Install gcc, g++, make and all the other build essentials:
apt-get install build-essential
Install YASM:
apt-get install yasm
Install Open SSL:
apt-get install openssl
Install Package Config:
apt-get install pkg-config
Install Git:
apt-get install git
Install Ant:
apt-get install ant-optional
Install JUnit:
apt-get install junit
Install MingGW to be able to build for Windows (mingw-w64 can do 32 and 64-bit Windows):
apt-get install mingw-w64
Download the LGPL configured Xuggle source code (Ed’s fork of the code from Jeff Wallace’s fork from the original GPL xuggle code) or the original GPL version:
LGPL: git clone https://github.com/e-d/xuggle-xuggler.git
GPL: git clone https://github.com/xuggle/xuggle-xuggler.git
Compile and build the JAR files (with binaries inside). Be sure to run the 64-bit Linux build on the 64-bit version of Ubuntu. Also note that between builds you will need to run “ant clobber” to remove all of the compiled files from the previous architecture. To build run:
(32/64-bit Linux): ant stage
(64-bit Windows): ant -Dbuild.configure.os=x86_64-w64-mingw32 stage
(32-bit Windows): ant -Dbuild.configure.os=i686-w64-mingw32 stage
The JAR files will be in the /dist/lib directory.
If you need the Linux binaries to additionally work on CentOS, you’ll now need to change the version of GCC and G++ to use 3.4 instead of 3.6.
Install GCC 4.4:
apt-get install gcc-4.4
Update symbolic links to use 4.4 (the arch-specific link will be different on 32-bit VM):
rm /usr/bin/gcc
ln -s /usr/bin/gcc-4.4 /usr/bin/gcc
rm /usr/bin/x86_64-linux-gnu-gcc
ln -s /usr/bin/x86_64-linux-gnu-gcc-4.4 /usr/bin/x86_64-linux-gnu-gcc
Install C++ (G++) 4.4:
apt-get install c++-4.4
Update symbolic links to use 4.4 (the arch-specific link will be different on 32-bit VM):
rm /usr/bin/cpp
ln -s /usr/bin/cpp-4.4 /usr/bin/cpp
rm /usr/bin/x86_64-linux-gnu-cpp
ln -s /usr/bin/x86_64-linux-gnu-cpp-4.4 /usr/bin/x86_64-linux-gnu-cpp
rm /usr/bin/g++
ln -s /usr/bin/g++-4.4 /usr/bin/g++
rm /usr/bin/x86_64-linux-gnu-g++
ln -s /usr/bin/x86_64-linux-gnu-g++-4.4 /usr/bin/x86_64-linux-gnu-g++
Verify default versions:
gcc --version
c++ --version
cpp --version
gcc --version
You can now run the builds the same way as before (you only need to re-build Linux binaries). The binaries will now be compatible with slightly older versions of many Linux distros (including CentOS compatibility). These 4.4 compiled binaries should still work everywhere the 4.6 compiled versions would run too.
Special thanks to this blog for pointing me in the right direction and giving me the majority of what I detailed above.
I want to build Angstrom kernel on Ubuntu 13.04 host machine using OpenEmbedded.
git clone git://github.com/Angstrom-distribution/setup-scripts.git
cd setup-scripts
MACHINE=beagleboard./oebb.sh config beagleboard
MACHINE=beagleboard./oebb.sh update
MACHINE=beagleboard./oebb.sh bitbake virtual/kernel
The reason of building kernel is to be able to cross-compile a kernel driver on host machine, targeting on Angstrom distribution (BeagleBoard). Beagleboard runs a prebuilt image of 2.6.32.
As I know, the cross-compile must target not only the Angstrom distribution, but the same kernel version that BeagleBoard runs. How does OE choose "preferred" version? Is there any way I can choose the kernel version that BitBake will build?
Depending on PREFERRED_PROVIDER_virtual/kernel you choose, you can specify the version
this is an example:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
PREFERRED_VERSION_linux-yocto ?= "3.10%"
remember the '%' means that numbers following 3.10 doesn't matter.
another example
PREFERRED_PROVIDER_virtual/kernel ?= "linux-imx"
PREFERRED_VERSION_linux-imx ?= "3.10.2"