I am using Petalinux 2017.2 and the included tools to build a Linux image for a Zynq ZC702 board. I am trying to add a pre-compiled executable to my rootfs with a bitbake recipe.
SUMMARY = "Demo on ARM-Linux"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = " \
file://Demo1.out \
"
FILES_${PN} = " \
/home/root/Demo/ \
/home/root/Demo/Demo1.out \
"
S = "${WORKDIR}"
do_install() {
install -d ${D}/home/root/Demo
install -m 0755 ${S}/Demo1.out ${D}/home/root/Demo
}
When I attempt to build the rootfs with my app included I get this error:
ERROR: demo-1.0-r0 do_package: objcopy failed with exit code 1 (cmd was 'arm-xilinx-linux-gnueabi-objcopy' --only-keep-debug '/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/Demo1.out' '/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/.debug/Demo1.out'):
arm-xilinx-linux-gnueabi-objcopy:/home/common/peta_proj_2017.2_secure/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/demo/1.0-r0/package/home/root/Demo/Demo1.out: File format not recognized
ERROR: demo-1.0-r0 do_package: Function failed: split_and_strip_files
I assume objcopy has an issue with my file having been compiled for arm-linux-gnueabihf, but I already know it works since I've tried copying it to the rootfs manually after Linux is booted and tested it. I would try to recompile it with the arm-xilinx-linux-gnueabi toolchain but it's missing some of the libraries I need. I don't know why objcopy is being called for this operation anyway. All I want is for it to move the file to the rootfs, but for some reason it's doing all this extra work on it. Is there a way I can make bitbake ignore the file's format?
looks like the problem is that objcopy is trying to strip symbols, and as you said, the toolchain used is not the same as the one it was used to build it.
You can try to setting:
INHIBIT_PACKAGE_STRIP="1"
somewhere (perhaps in your local.conf).
It should skip the step on which the build system tries to strip debug symbols from binaries hence will probably not invoke objcopy.
1 [https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-INHIBIT_PACKAGE_STRIP]1
Related
I want to build my own operating system ， but how install i686-elf-gcc in manjaro
i I found a tool（https://github.com/lordmilko/i686-elf-tools）, but it can only be run in ubuntu
A simple solution would be to build the compiler yourself. I went through the same thing recently. If you are into operating system development, you won't be able to avoid looking at the compiler in more detail and building cross compilation tools anyway.
Building your own compiler
The build process can be roughly divided into 4 steps:
Install all dependencies necessary for the build. If I remember correctly, you can get everything from the official package sources in Arch Linux. Make sure that these packages/tools are present: make, bison, flex, gmp, mpc, mpfr, texinfo, libisoburn, mtools.
Download the source code of binutils (GNU's assembler and binary tools) and gcc (the GNU compiler collection). I recommend using the newest versions at the bottom of the respective pages.
Decide where your new compiler should be installed. Although it sounds tempting, it should not end up in any system directory, rather somewhere in your home folder. I used $HOME/tools/crc to store my cross-compilation tools. You can at it to your $PATH lateron for convenience.
Do the actual build. First of all: The build takes a while and needs one or the other command line switch. Do not omit any of them. The build may pass and problems may occur later. Just follow the instructions below.
The actual build process
The first thing to do is to compile binutils, because it is needed for the gcc build. For convenience set a few shell variables to minimize error sources:
# This is where the tools will end up
export PREFIX="$HOME/tools/crc"
# Prefix of the produced assemblies (for example i686-elf-gcc)
export TARGET=i686-elf
# Add the new installation to the PATH variable temporarily
# since it is required for the gcc build
export PATH="$PREFIX/bin:$PATH"
Now create a new directory somewhere and extract both the gcc and binutils source code archives in there. You should end up with two subdirectories like yourdir/binutils-x.y.z and yourdir/gcc-x.y.z. It is recommended to do the build in an empty directory, so create yourdir/build-binutils and yourdir/build-gcc as well. Notice: These directories are not placed inside the source directories!
Building binutils
cd into the yourdir/build-binutils directory and run the following commands. Replace the x.y.z part with your version.
../binutils-x.y.z/configure \
--target=$TARGET \
--prefix="$PREFIX" \
--with-sysroot \
--disable-nls \
--disable-werror
make
make install
Now check the installation with which -- $TARGET-as. This will return the location of i686-elf-as, which is the assembler we just build.
Building gcc
cd into the yourdir/build-gcc directory. The process is pretty much the same as with binutils above:
../gcc-x.y.z/configure \
--target=$TARGET \
--prefix="$PREFIX" \
--disable-nls \
--enable-languages=c,c++ \
--without-headers
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
Verify the build
Check the installation by invoking i686-elf-gcc --version. If you used the same values as I, this can be done with $HOME/tools/crc/bin/$TARGET-gcc --version.
I have my own .so closed source library and provide header file. My .so library file should be inside the yocto image, but header file should be used during another projects compilation only.
Here is yocto receipt:
SUMMARY = "foo library"
LICENSE = "CLOSED"
SECTION = "libs"
SRC_URI = "file://usr/lib/libfoo.so \
file://usr/include/foo.h "
S = "${WORKDIR}"
inherit autotools pkgconfig
do_compile() {
}
do_install() {
install -d ${D}/usr/lib
install -m 0755 ${WORKDIR}/usr/lib/libfoo.so ${D}/usr/lib/libfoo.so.1
ln -s /usr/lib/libfoo.so.1 ${D}/usr/lib/libfoo.so
install -d ${D}/usr/include
install -m 0644 ${WORKDIR}/usr/include/foo.h ${D}/usr/include/
}
FILES_${PN}-dev += "${includedir} "
FILES_${PN} += "/usr/lib/libfoo.so \
/usr/lib/libfoo.so.1"
PROVIDES += "libfoo"
I expect ${PN} package has libfoo.so and libfoo.so.1 and ${PN}-dev package has only one header file. But yocto bitbake copies only libfoo.so.1 in ${PN} and libfoo.so is in ${PN}-dev packet.
Could you please help me how to move so file into ${PN} package?
The behavior is correct here. Non-versioned .so files are installed in the -dev package because packages in the system should link against versioned files.
It is pretty uncommon to need to install a -dev package in an image, so effectively, only your versioned so file will make it.
As you saw already, the header is in the -dev package so won't make it to the image except if the -dev package is explicitly added to the image.
Because your header file is in includedir which is one of the directories used for the sysroot of other recipes (c.f. SYSROOT_DIRS), it'll be available to other recipes at build time. Same for your library as it's installed in lib_dir (also in aforementioned variable).
So the current behavior is expected. It is not clear why exactly you want your non-versioned symlink in the main package too.
If for some reason it's really what you want to do, you just need to add the following to your recipe:
SOLIBS = ".so"
FILES_SOLIBSDEV = ""
c.f. https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries
I am trying to build a custom Linux image using the Poky 2.6(thud) with ROS meta layer(thud-draft) in it. The image is built for a x86-64 system . The contents of my bblayers.conf file are given below
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
ROS_DISTRO = "melodic"
BBLAYERS ?= " \
/home/kogrob/devel/poky/meta \
/home/kogrob/devel/poky/meta-poky \
/home/kogrob/devel/poky/meta-yocto-bsp \
/home/kogrob/devel/poky/meta-openembedded/meta-oe \
/home/kogrob/devel/poky/meta-ros/meta-ros-common \
/home/kogrob/devel/poky/meta-ros/meta-ros1-melodic \
/home/kogrob/devel/poky/meta-openembedded/meta-python \
/home/kogrob/devel/poky/meta-ros/meta-ros-backports-warrior \
/home/kogrob/devel/poky/meta-ros/meta-ros1 \
"
The build failed with the following errors
Function failed: do_compile (log file is located at /home/kogrob/poky/build-toaster-2/tmp/work/core2-64-poky-linux/btrfs-tools/4.17.1-r0/temp/log.do_compile.26496)
Function failed: do_compile (log file is located at /home/kogrob/poky/build-toaster-2/tmp/work/core2-64-poky-linux/boost/1.68.0-r0/temp/log.do_compile.27908)
The boost build when it is build seperately using bitbake boost but the btrfs-tools fails everytime. What is the need of btrfs-tools and Is it possible to remove btrfs-tools and build an image without it.
The log files can be found here:
log.do_compile.26496
log.do_compile.27908
On my Unbuntu host (Ubuntu 16.04.6 LTS x86_64), try the command:
pip install setuptools
but it doens't work, because the do_compile() use yocto generated python binary, not the one Ubuntu builtin, something like this:
build/tmp/work/aarch64-sdrv-linux/btrfs-tools/4.17.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3
.
Scenario:
I am working with yocto linux recipes. I am trying to make a recipe which simply copies a prebuilt MyLibrary.a and its headers available on the built linux image. So, I have a libMyLibrary.a which I want to copy to /usr/lib. And MyLibrary's headers files MyLibrary.h and MyLibrary.hpp into /usr/include. Note that MyLibrary is already built and I just want to copy the binary and headers into desired locations of the built linux image.
So following is the recipe:
SUMMARY = "Script to make a static library available in yocto linux image"
LICENSE = "CLOSED"
FILES_${PN} += "${libdir}"
SRC_URI = "file://libMyLibrary.a \
file://MyLibrary..hpp \
file://MyLibrary..h \
"
S = "${WORKDIR}"
do_install () {
install -d ${D}${libdir}
install -d ${D}${includedir}
install -m 0644 ${WORKDIR}/libMyLibrary.a ${D}${libdir}/
install -m 0644 ${WORKDIR}/MyLibrary.h ${D}${includedir}/
install -m 0644 ${WORKDIR}/MyLibrary.hpp ${D}${includedir}/
}
Initially I started with getting some errors in the do_install step. I resolved them but now the do_rootfs step is complaining about my bb file that is mylibrary_1.0.bb. I am pretty sure that the parent recipe that calls my recipe has no errors since it builds a lot of other recipes and mine is just additional to it. Also, the errors started to appear after I wrote the do_install step.
Question
Can someone point out what is wrong with my recipe above?
Or is there a simple example recipe which copies a .a and its headers into the desired location i.e. /usr/lib and /usr/include like I am doing above?
Explaining what the errors are would be useful. Note that because your recipe only ships a static library and headers it won't generate a mylibrary package, which is probably what the errors are about.
I've been trying to compile a static QEMU executable for Windows on a Debian box, and ran into some problems. (I'm using this guide as a reference.)
When I compile without the static flag everything works but when I compile using the static flag I get the following error during the call to configure:
ERROR: zlib check failed
Make sure to have the zlib libs and headers installed.
This is the command line:
WORK=/media/Work/qemu
cd $WORK/build/w32
(export PKG_CONFIG_PATH=$WORK/install/w32/lib/pkgconfig ;
export PKG_CONFIG_PREFIX=$WORK/install/w32 ;
#export BASH_X=-x ;
bash $BASH_X ../../qemu.git/configure --target-list="i386-softmmu" \
--cross-prefix=i686-w64-mingw32- \
--extra-ldflags="-L$WORK/install/w32/lib" \
--extra-cflags="-I$WORK/install/w32/include" \
--static \
)
You can disable the zlib test using the command line input
./configure --disable-zlib-test
Zlib will be needed to build qemu, but it will not test for the library during configure. If the library is available in the proper location during build process, you can try the above command to proceed.