[yocto] Dependencies with third party binaries

[simon.zeni at posteo.net]

Yes, the image will be deployed on the CI to build our software. I 
managed to just drop the files at some place, but it requires user input 
to install the compiler.

Simon

On 03.05.2019 01:19, Burton, Ross wrote:
> Do you mean you want to build packages to run icc on the target?
> 
> On Thu, 2 May 2019 at 23:46, <simon.zeni at posteo.net> wrote:
>> 
>> The layer that comes with the Intel system studio only contains the
>> runtime libraries, not the compiler itself.
>> 
>> Simon
>> 
>> On 03.05.2019 00:15, Burton, Ross wrote:
>> > Why don't you use the layer that comes with the Intel compiler?
>> >
>> > Ross
>> >
>> > On Thu, 2 May 2019 at 23:15, <simon.zeni at posteo.net> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm currently working on repackaging the 2016 Intel compiler and I am
>> >> stuck at the dependency resolution.
>> >>
>> >> I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs
>> >> from the parallel-studio-xe [2] archive and extracts the content of
>> >> the
>> >> RPMs to get the binaries. I already have the RPMs extracted from the
>> >> tarball and stored in a git repo. Not the ideal solution, but good
>> >> enough for now.
>> >>
>> >> The `bitbake` command for the recipe is passing after disabling a
>> >> couple
>> >> of QA errors (too much for my taste), but the recipe for the
>> >> `core-image` fails at the dependency
>> >> resolution. From what I understand, all of the binaries inside of the
>> >> `FILES_${PN}` are checked, and one (or more) fails at the dependency
>> >> check with the following message :
>> >>
>> >> ```
>> >> Error:
>> >>   Problem: conflicting requests
>> >>    - nothing provides ld-linux-k1om.so.2()(64bit) needed by
>> >> icc-2016+1-r0.corei7_64
>> >> ```
>> >>
>> >> This shared library seems to be Intel related but I cannot find it in
>> >> all of the RPMs contained in the initial tarball. It is also not
>> >> needed
>> >> to run the compiler, I was able to execute the `icc` and `icpc` (the
>> >> c++
>> >> compiler) binaries from the devshell.
>> >>
>> >> I know this is wrong and against every yocto principles, but is there
>> >> a
>> >> way to skip the dependenciey resolution for a specific recipe ? Or is
>> >> there a recipe made by Intel that I missed ?
>> >> I'm also open to any suggestions on how to tackle this task.
>> >>
>> >> Here's my recipe so far :
>> >>
>> >> ```
>> >> LICENSE = "CLOSED"
>> >> LIC_FILES_CHKSUM = ""
>> >>
>> >> DEPENDS += "libarchive-native"
>> >>
>> >> SRC_URI = # omitted
>> >>
>> >> PV = "2016-1"
>> >> SRCREV = "${AUTOREV}"
>> >>
>> >> S = "${WORKDIR}/git"
>> >>
>> >> extract_rpms() {
>> >> for rpm_file in ${S}/$1; do
>> >>         bsdtar -xf ${rpm_file} -C $2
>> >> done
>> >> }
>> >>
>> >> # Skip the unwanted steps
>> >> do_configure[noexec] = "1"
>> >> do_compile[noexec] = "1"
>> >>
>> >> do_install () {
>> >> extract_rpms 'intel-icc*.rpm' ${D}
>> >> extract_rpms 'intel-comp*.rpm' ${D}
>> >> extract_rpms 'intel-ccomp*.rpm' ${D}
>> >> extract_rpms 'intel-openmp*.rpm' ${D}
>> >> }
>> >>
>> >> do_package_qa[noexec] = "1"
>> >>
>> >> ALLOW_EMPTY_${PN} = "1"
>> >>
>> >> FILES_SOLIBSDEV = ""
>> >> FILES_${PN} += "/opt/intel/*"
>> >>
>> >> INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev
>> >> file-rdeps
>> >> build-deps"
>> >>
>> >> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>> >> INHIBIT_PACKAGE_STRIP = "1"
>> >>
>> >> ```
>> >>
>> >> Thanks,
>> >>
>> >> Simon Zeni
>> >>
>> >> [1]:
>> >> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe&id=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
>> >> [2]:
>> >> http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz
>> >> --
>> >> _______________________________________________
>> >> yocto mailing list
>> >> yocto at yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto