Search code examples
javarpmyoctobitbakeopenembedded

Smart can't install...no package provides shared object file


Problem

I'm attempting to create a Bitbake recipe which will install Oracle JRE 8 onto my target OS.

I've tried to use metadata from meta-oracle-java, but had some difficulties due to one of the .inc files which are provided for general JREs has a JRE-7-specific URI.

I've changed some of the metadata from meta-oracle-java and created my own recipe to do this install.

Tests

A Build of the JRE Recipe by Itself

When building the recipe by itself:

bitbake oracle-jse-jre

The build completes without error. I've added a dependency on libav into the oracle-jse-jre recipe, so I can do the following from TMPDIR:

$ find . -name libavformat*so 
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54.20.4
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so
./work/core2-64-poky-linux/libav/9.18-r0/sysroot-destdir/usr/lib/libavformat.so.54
./sysroots/genericx86-64/usr/lib/libavformat.so.54.20.4
./sysroots/genericx86-64/usr/lib/libavformat.so
./sysroots/genericx86-64/usr/lib/libavformat.so.54

Runtime Dependency Success

If I add the default package from the oracle-jse-jre recipe to RDEPENDS_${PN} of another recipe xenoros_0.1.bb, I can run bitbake xenoros and build without errors.

Core Image Failure

If I add xenoros to the IMAGE_INSTALL variable of a core-image-xenoros, the build fails with the following error:

ERROR: Unable to install packages. Command '/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/sysroots/x86_64-linux/usr/bin/smart --log-level=warning --data-dir=/home/presslertj/yocto-OS/poky-jethro-build/build/tmp/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/rootfs/var/lib/smart install -y message-generation@core2_64 catkin@core2_64 python-distutils@core2_64 ldd@core2_64 xenoros@core2_64 rosgraph@core2_64 gedit@core2_64 actionlib@core2_64 python-compression@core2_64 dhcp-server@core2_64 libpthread-stubs@core2_64 tf2@core2_64 python-email@core2_64 catkin-dev@core2_64 git@core2_64 rosbash@core2_64 python-json@core2_64 python-wstool@core2_64 connman@core2_64 ros-config@core2_64 packagegroup-core-boot@genericx86_64 libsdl-1.2-0@core2_64 rosjava@core2_64 quagga@core2_64 nginx@core2_64 rospy@core2_64 apt@core2_64 libc6@core2_64 netcat@core2_64 shadow@core2_64 bash@core2_64 roscpp@core2_64 roslaunch@core2_64 run-postinsts@all python-rosinstall@core2_64 elfutils@core2_64 openssl@core2_64 font-alias@all gradle@core2_64 python-catkin-pkg@core2_64 catkin-runtime@core2_64 catkin-runtime-dev@core2_64 pciutils@core2_64 base-passwd@core2_64' returned 1:
Loading cache...
Updating cache...               ######################################## [100%]

Computing transaction...error: Can't install oracle-jse-jre-1.8.0-u77r0@core2_64: no package provides libavformat.so.53(LIBAVFORMAT_53)(64bit)

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/presslertj/yocto-OS/poky-jethro-build/build/tmip/work/genericx86_64-poky-linux/core-image-my-server/1.0-r0/temp/log.do_rootfs.22073
ERROR: Task 7 (/home/presslertj/yocto-OS/poky-jethro-build/meta-myLayer/recipes-core/images/core-image-my-server.bb, do_rootfs) failed with exit code '1'

Looking inside TMPDIR, I can find this:

/sysroots/genericx86-64/usr/lib/libavformat.so.54

It seems there's a version mismatch, where smart expects version 53, but 54 is provided.

Reverting libav's version

Just to test what's going on, I've made a recipe which fetches version 0.8.17 of libav (which uses version 53). When using this instead of 9.18, I have the exact opposite problem, that smart expects but can't find version 54.

Questions

  1. How does smart determine the version number for these shared object files?
  2. What about the do_rootfs() task causes the build to fail at this specific time?
  3. Is there a simple resolution to my specific problem?

Solution

  • 1) It's not smart, but rather rpmbuild, that is adding dependencies derived from the ELF DT_NEEDED field (see elfutils -a).

    2) The do_rootfs() task is failing because of unresolved dependencies.

    3) Since you are using Poky/Yocto and rpm5, there is a simple way to mask the issue (substituting whatever dependencies are causing you heartburn)

    echo "unresoved_dependency" > /etc/rpm/sysinfo/Providename
    

    That is just a band-aid; you still need to figure out the packaging issues rather than masking the underlying problem with how you are building rpm packages.