Dependencies with third party binaries


simon.zeni@...
 

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


Burton, Ross <ross.burton@...>
 

Why don't you use the layer that comes with the Intel compiler?

Ross

On Thu, 2 May 2019 at 23:15, <simon.zeni@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto


simon.zeni@...
 

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@...> 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@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto