I'm trying to debug my application on the target device. I'm using gdb-multiarch on the host and gdb-server on the target. Everything works fine with breakpoints and stepping.
My Problem is that my application is dependent on some of my on libs. When I step into a function of these libs the source code is not found. There is no /usr/src in my recipe-sysroot folder.
Steps I have done:
Generate eSDK: bitbake my-image -c populate_sdk_ext
Installed the eSDK to ~/my_sdk
devtool modify -n my-recipe ~/repositories/my-application
devtool build my-recipe
When I check the my-image.tar.gz generated by bitbake then I can find all the /usr/src folder. But the eSDK and devtool don't extract the files to the recipe-sysroot. How can I get this done? Is there an option I'm missing?
did you try to use devtool add to add the source ? in yocto the packages are usually debug free and source free, for example net-utils have net-util, netutil-dbg, net-util-dev and net-util-src.
Related
Some years ago on Ubuntu 16.0.4 I've used this library: git clone https://github.com/Beckhoff/ADS and using only the make command I got build, compile and finally on the main directory I found a file called AdsLib-Linux.a and maybe nothing more than this.
Now I'm on Ubuntu 20.04 I need this library once again but this times make dosn't produce the same output and looking forth to the ReadMe instructions I finally used that instead of make:
meson build
ninja -C build
That now create a new directory build but no .a file as before on the root directory. Instead a new file in the build directory libADSLib.a is there. The same thing happens using right the make command.
Maybe the author changed over the years something on the config files or the behavior of the tools have changed, but I cannot get the former file anymore and I need it for other referencing code that now is not executing anymore.
Looking to the MakeFile I found that in the example folder, differently from the one on the parent directory, the MakeFile has something like that:
$(warning ATTENTION make is deprecated and superseeded by meson)
...
${PROGRAM}: LIB_NAME = ../AdsLib-${OS_NAME}.a
...
But all i've tried reading the guides on meson and ninja about setup, configure, build, and so on, did not produce anymore that file.
I've tried also to first build and then copy all files form the example folder to the parent directory and then build again, but again no .a file there.
How's the right way to configure the build process corectly so that this -Linux.a file is created. Or if not possibile anymore, what does it now produce I can use instead of what produced before?
Meson is a build system generator, similar to CMake or somewhat like ./configure, you need to run meson, then run ninja to actually build something.
You need to run both meson and ninja:
meson setup builddir
ninja -C builddir
Once you do that successfully, there will be a libAdsLib.a inside the builddir directory.
Let me correct a bit #dcbaker, according to their README you should setup build as build directory:
# configure meson to build the library into "build" dir
meson build
# let ninja build the library
ninja -C build
Of course, in general, it shouldn't be specific, but their example code is written in a weird way so this path is hard-coded. So, to use the example:
# configure meson to build example into "build" dir
meson example/build example
# let ninja build the example
ninja -C example/build
# and run the example
./example/build/example
About the library: it's now libAdsLib.a and produced in build directory. The name is set here and it's now in linux naming style, the old one - not. So, you have options:
Update your configuration/build files (Makefile?) where you use it
Copy or make symbolic link, e.g.
$ ln -s <>/build/libAdsLib.a <target_path>/AdsLib-Linux.a
Above it's very dependent on your development environment, do you have installation or setup scripts for it? do you permissions to modify/configure parameters for target application? do you need to support both old and new names? - many questions not related to original question about meson.
I want to cross-compile my Rust application on macOS to a Raspberry Pi 2. I searched a lot, but did not find a working solution. The last solution I tried was following this answer, but I couldn't get it to work.
macOS version: 10.13.5 (High Sierra)
rustup version: 1.11.0
cargo version: 1.26.0
What I did:
I cloned raspberrypi/tools
Installed arm-unknown-linux-gnueabihf and
armv7-unknown-linux-gnueabihf toolchains via rustup
Created .cargo/config file in the root of my project with following content
[target.armv-unknown-linux-gnueabihf]
linker = "/Users/user/Documents/Programming/RustProjects/hello-pi/../../Utils/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc"
Then I run cargo build --target=arm-unknown-linux-gnueabihf
I get the following error:
linking with /Users/user/Documents/Programming/RustProjects/hello-pi/../../Utils/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc failed: exit code: 126
....
cannot execute binary file
It seems that I cannot run the ...gcc binary on my macOS machine. What would be the right way to cross-compile my Rust application from macOS to the ARM architecture for a Raspberry Pi 2?
rust-std library relies on glibc for things like syscalls and other low-level stuff, in order to cross-compile a Rust binary, one needs the appropriate C toolchain to be present as well. And this is where crosstool-NG comes into play.
crosstool-NG is in the toolchain building business. You’re going to use it to build yourself a toolchain for linking against ARMv7-compatible glibc, which will in turn allow you to successfully build your Rust binary for the Pi.
Clone the repo to a good location and bootstrap it:
cd /Users/USER
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
./bootstrap
Configure the installation and run it. To set where the tool goes on install, run:
./configure --prefix=$PWD
make
make install
export PATH="${PATH}:${PWD}/bin"
If all things went as expected, you should be able to run ct-ng version and verify the tool’s ready to go.
Configure the tool to build your ARMv7 toolchain. Luckily, crosstool-NG comes with some preset configurations, namely armv7-rpi2-linux-gnueabihf. Run:
ct-ng armv7-rpi2-linux-gnueabihf
There should be some output indicating that it’s now configured for armv7-rpi2-linux-gnueabihf. You just need to tell ct-ng where the toolchain ought to go:
mkdir /Users/USER/ct-ng-toolchains
cd /Users/USER/ct-ng-toolchains
ct-ng menuconfig
It can be overwhelming, as there are a ton of options, but stick to the Paths and misc options ---> menu option. Highlight it and hit Enter.
Under *** crosstool-NG behavior ***, scroll down until you see this long string:
(${CT_PREFIX:-${HOME}/x-tools}/${CT_HOST:+HOST-${CT_HOST}/}${CT_TARGET}) Prefix directory
- Hit Enter, delete the contents, and replace it with /Users/USER/ct-ng-toolchains.
- When you’re finished, hit Enter to confirm, scroll over and save, and then exit the configurator.
Build your toolchain (this may take half an hour):
ct-ng build
If it worked successfully, You should see a great many binaries now in /Users/USER/ct-ng-toolchains/armv7-rpi2-linux-gnueabihf/bin, namely armv7-rpi2-linux-gnueabihf-gcc.
For cargo to build using your new cross-compiler, you must:
Add the bin folder listed above to your PATH:
export PATH="${PATH}:/Users/USER/ct-ng-toolchains/armv7-rpi2-linux-gnueabihf/bin"
Update (or create) your global /Users/USER/.cargo/config file with (you can avoid this and use it in local .cargo/config):
[target.armv7-unknown-linux-gnueabihf]
linker = "armv7-rpi2-linux-gnueabihf-gcc"
3.Return to your Rust project and rerun cargo build:
cd /Users/USER/rust/hello
cargo build --target=armv7-unknown-linux-gnueabihf
The output should be something similar to:
Compiling hello v0.1.0 (file:///Users/USER/rust/hello)
Finished dev [unoptimized + debuginfo] target(s) in 0.85 secs
SCP your file over to the RPi and run the binary remotely:
scp target/armv7-unknown-linux-gnueabihf/debug/hello pi#192.168.1.43:
ssh pi#192.168.3.155 'chmod +x ~/hello && ~/hello'
Hello, world!
Credit goes to Kappel Codes I tried to summarize it here, as I found this question hours before I get that article :)
apps:
library-sample:
command: library_sample
parts:
library:
source: https://github.com/the/sample.git
plugin: cmake
When snapcraft runs the cmake install, "library" will be installed on the system (as I would expect). Also, cmake will also produce a test application in a samples folder under the build directory.
I would like to promote the sample (generated by the "part") to be an installed app within the snap package.
How do I use snap YAML to move from a nested directory under the build folder, into the snaps /bin folder?
You can do this by utilizing Snapcraft's scriptlets. Specifically, the install scriptlet. They essentially allow you to modify the behavior of the build process by customizing sections of it. In the build lifecycle step, snapcraft esentially runs cmake && make && make install, but make install doesn't do everything you want it to do. The install scriptlet runs right after make install, so you can do something like this:
parts:
library:
source: https://github.com/the/sample.git
plugin: cmake
install: |
cp -r path/to/samples $SNAPCRAFT_PART_INSTALL/
Now clean the build step with snapcraft clean -s build and run snapcraft again. Then the samples directory will end up in the final snap.
Right now I am trying to compile Courguette in order to generate a diff patch. The source and some documentation can be found in the following link:
Courguette
I downloaded it but I don't find the way of compiling it.
I have Googled and found some references even to this forum, such as:
StackOverflow link
And other references:
Chromium Linux build instructions
After reading things about ninja and gpy I decided to install them, but there are not references to a .ninja file. I find a courguette.gyp file but using gpy I neither get it compiled...
I am following the guide they provide:
Installed the depot_tools and added to the path.
gclient runhooks
gclient sync
And when I execute gn gen out/Default it fails with the following message:
gn.py: Could not find gn executable at: ~/binary_diff_tools/courgette-master/courgette/buildtools/linux64/gn
Then I used git to pull from the repository the buildtools, but I get the same result.
Any help will be appreciated.
Best regards,
Iván
Ok... It seems that is needed to install all Chromium dependencies before being able to compile courgette so... it must be done as follows:
Install depot_tools git clone and you will have them installed.
After including the depot_tools in your patch (.profile or .bashsrc for example as indicate the depot_tools installation tutorial) execute fetch chromium ouside the depot_tools folder ( it always failed me when I executed it inside the same folder).
I want to build it in Debian so I have to do "gclient runhooks" instead of the .sh script for Ubuntu.
ninja -C out/Default courgette
You will find the executable in the folder out/Default, so ./courgette and it will indicate you the right parameters in order to generate your patch properly.
Best regards,
Iván.
I am working on a kernel module for a project using Yocto Linux (version 1.3). I want to use the kernel headers and the compiler and libraries from my Yocto project, but develop the kernel module without needing to run bitbake every time. My initial solution to this was to execute the devshell task and extract the environment variables using something like this:
bitbake mykernel -c devshell
Then in the new xterm window bitbake opened for me:
env | sed 's/\=\(.*\)/\="\1"/' > buildenv #put quotes around r-values in env listing
^D #(I leave the devshell)
Then copy this to my development directory and source it before running make with all of its options
KERNEL_PATH=/mypathto/build/tmp/sysroots/socfpga_cyclone5/usr/src/kernel
source ./buildenv && make -C $KERNEL_PATH V=1 M=`pwd` \
ARCH=arm CROSS-COMPILE=arm-linux-gnueabihf- \
KERNEL_VERSION=3.13.0-00298-g3c7cbb9 \
CC="arm-linux-gnueabihf-gcc -mno-thumb-interwork -marm" \
LD=arm-linux-gnueabihf-ld AR=arm-linux-gnueabihf-ar
Now to my questions:
Am I going about this completely wrong? What is the recommended way to cross-develop kernel modules? I am doing it this way because I don't want to open a bitbake devshell and do my code development in there every time.
This sort of works (I can compile working modules) but the make script gives me an error message saying that the kernel configuration is invalid. I have also tried this with KERNEL_PATH set to the the kernel package git directory (build/tmp/work///git (which contains what appears to be a valid .config file) and I get a similar error.
How can I extract the env without needing to open a devshell? I would like to write a script that extracts it so my coworkers don't have to do it manually. The devshell command opens a completely separate Xterm window, which rather dampens its scriptability...
the sdk installer is what you are looking for:
bitbake your-image -c populate_sdk
then, from your build directory go to tmp/deploy/sdk
and execute the generated shell script.
this script will allow you to generate and install an sdk.
Not only the sdk will allow you to (cross) compile your kernel by providing the needed environment variables and tools, but it will also provide a sysroot + a standalone toolchain to help you easily (and by easily I mean really easily) crosscompile applications with the autotools (as long as you provide Makefile.am and configure.ac)
just source the environment-setup-* file, got to your kernel directory and compile.
Or, for application developpment based on the autotools,
go to the folder containing your project (sources + Makefile.am and configure.ac)
and do:
libtoolize --automake
aclocal
autoconf
automake -a
now your project is ready for compilation:
./configure $CONFIGURE_FLAGS
make
make install DESTDIR=path/to/destination/dir
If you're after a quick hack, instead of Ayman's more complete solution, the scripts run to complete each build stage are available in the directory:
./build/tmp/work/{target_platform}/{package}/{version}/temp/run.do_{build_stage}
These scripts can be run standalone from the ./temp/ directory, and contain all of the environment variables required.