I need to use webrtc in my Android native application.
After downloading the source for webrtc, here are the primary steps for building webrtc:
$ export GYP_DEFINES="OS=Android..."
$ gclient runhooks
$ ninja -C out/Release AppRTCDemo
The target architecture, ARM or x86, must be defined through GYP_DEFINES.
I need to decide if I must create platform-specific directories for webrtc source files. Does gclient runhooks modify webrtc source code in any way? Regards.
Related
I'm trying to use redis to broadcast events on laravel but php isn't able to load this extension due to wrong architecture.
I used pecl install redis to install the extension and I'm wondering if there's a flag I can pass to build/install using a diff architecture (arm64)
PHP Startup: Unable to load dynamic library 'redis.so'
no suitable image found. Did find:
redis.so: mach-o, but wrong architecture
running lipo -info redis.so results in redis.so is architecture: x86_64
But I think my machine (m1 macbook) requires an arm64 extension. (as I see other .so files with the correct architecture.
Any help on how I can create this would be greatly appreciated.
I've tried to download the tar file, extract and make, but on make test, the device actually crashes during the process, or overheats and just doesn't finish executing make test.
One way is to use the terminal in x86 mode on top of Rosetta 2.
Go to where the terminal application is located in the finder (Applications/Utilities/Terminal)
Click it once so it highlights then press cmd + I to open up the information tab.
Hit this:
to open the terminal in the Rosetta mode.
Open the terminal
This doesn't always work for the nature of some programs but it is worth giving it a shot.
I want to run hello.exe file generated on Windows OS platfrom for simpe hello.c file on IMX8M yocto linux board. I am very new to use this board and I am not finding any helping material on the same. Can anyone guide me is it possible or not and where can I find related documents.
If it's not possible, what are the other ways to run .exe generated from any HOST OS to Yocto Linux board.
I think there is some misunderstanding.
As the host and the device are not the same architecture (x64/ARM) and the same OS (Windows/Linux), you need to cross-compile your code. This is done by using a specific compiler, able to run on your host machine, to generate your binary for your device machine.
If you want to compile an application for your iMX8M from your Windows computer, you will need to find a cross-compiler toolchain able to run on Windows, generating binaries for Linux ARM architecture.
If you use Yocto, you can generate a SDK, which contains a cross-compiler toolchain by using bitbake <image> -c populate_sdk or bitbake <image> -c do_populate_sdk (depending on your Yocto version).
By default Yocto generates a SDK for a Linux host, so you will need to develop on a Linux OS.
There is aslo a specific meta that helps to generate a SDK for Windows: meta-mingw
/opt/arduino-1.6.6/hardware/tools/avr/bin/avrdude: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
I having this problem when I'm trying to upload sketch into arduino. IDE continue writing that uploading. I already tried to dialout, that doesn't work in my case. I'm using arduino IDE 1.6.6, because on newer versions I have bigger problems. I have debian Elementary 5.0 Juno on my desktop
Finally I understood that version of libreadline is matter, so i created symlink from 7th to 6th libreadline version
cd /lib/x86_64-linux-gnu
sudo ln -s libreadline.so.7.0 libreadline.so.6
I'm confused about the environment. Using MSYS2 under Windows, I want to compile, say, the boost library:
http://www.boost.org/users/history/version_1_64_0.html
What file I have to download? The one for Windows or the one for unix?
MSYS2 is a not a Unix environment. It is a hybrid environment made up of these main components:
POSIX-emulation layer called msys-2.0.dll, which is a fork of cygwin.
Tools like GNU Make, Bash, and ls that depend on the msys-2.0.dll runtime.
pacman, another msys-2.0.dll program, that lets you install precompiled packages from the MSYS2 developers.
Native Windows software, which lives under the /mingw32 (for 32-bit) and /mingw64 (for 64-bit) directories.
Anyway, it seems like you are just getting started with MSYS2 and don't know much about it. If your goal is to write native Windows software that could some day be used outside of MSYS2, you should install the native Windows version of Boost provided by the MSYS2 developers. So run one of the commands below:
pacman -S mingw-w64-i686-boost
or
pacman -S mingw-w64-x86_64-boost
Then make sure you are using the right flavor of MSYS2 shell, and make sure you install the corresponding GCC toolchain. For 32-bit development, you must launch MSYS2 with the "MinGW-w64 32-bit Shell" shortcut and use pacman to install mingw-w64-i686-toolchain (pacman -S mingw-w64-i686-toolchain).
If you try to download binaries from boost's website, you will likely run into all sorts of compatibility issues. It's better to use software built using an MSYS2 GCC toolchain, especially if MSYS2 already has a package for that software.
I am trying to test Debian packages which are built on an x86 Linux system, but which will be executed on an ARM architecture. My {pre,post}{inst,rm} scripts are failing with a "exec format error" because the /bin/bash in the chroot'd environment, which is an image of a flash filesystem, are ARM binaries, not x86 binaries.
What I'm looking for, but cannot find, is an option to dpkg which is like --root, but which doesn't use chroot. I'd presumably need to know the name of some environmental variable (?) which contains the name of the parameter to --root.
It's probably easier to make the /bin/bash (and everything else) in the chroot executable.
Install qemu-user-static on the host. That will give you QEMU user space emulators for all architectures in static versions — so no complications with dynamic libraries in the chroot. It also configures binfmt support to execute ARM binaries with /usr/bin/qemu-arm-static.
Copy /usr/bin/qemu-arm-static into the /usr/bin of the chroot. Now you should be able to chroot and run programs normally. That way your Debian packages can be tested chrooted into their (emulated) native environment.
Alternatively to the good suggestion to use qemu, starting with dpkg 1.18.5 you could use --instdir in conjunction with --force-script-chrootless. Depending on the maintainer scripts you might need to adapt them to make use of the DPKG_ROOT environment variable. There's more information in the dpkg man page.