All of lore.kernel.org
 help / color / mirror / Atom feed
* Dependencies with third party binaries
@ 2019-05-02 22:14 simon.zeni
  2019-05-02 22:15 ` Burton, Ross
  0 siblings, 1 reply; 4+ messages in thread
From: simon.zeni @ 2019-05-02 22:14 UTC (permalink / raw)
  To: Yocto

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Dependencies with third party binaries
  2019-05-02 22:14 Dependencies with third party binaries simon.zeni
@ 2019-05-02 22:15 ` Burton, Ross
       [not found]   ` <0b69463845463a6776c00441492f4bc0@posteo.net>
  0 siblings, 1 reply; 4+ messages in thread
From: Burton, Ross @ 2019-05-02 22:15 UTC (permalink / raw)
  To: simon.zeni; +Cc: Yocto

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

Ross

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Dependencies with third party binaries
       [not found]     ` <CAJTo0LZjXghuNNJxXOODiWJ7psAS0+SuivP34rb2Vqjy-iz5zQ@mail.gmail.com>
@ 2019-05-02 23:38       ` simon.zeni
  0 siblings, 0 replies; 4+ messages in thread
From: simon.zeni @ 2019-05-02 23:38 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Yocto

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Dependencies with third party binaries
@ 2019-05-02 18:13 simon.zeni
  0 siblings, 0 replies; 4+ messages in thread
From: simon.zeni @ 2019-05-02 18:13 UTC (permalink / raw)
  To: yocto

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-05-02 23:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-02 22:14 Dependencies with third party binaries simon.zeni
2019-05-02 22:15 ` Burton, Ross
     [not found]   ` <0b69463845463a6776c00441492f4bc0@posteo.net>
     [not found]     ` <CAJTo0LZjXghuNNJxXOODiWJ7psAS0+SuivP34rb2Vqjy-iz5zQ@mail.gmail.com>
2019-05-02 23:38       ` simon.zeni
  -- strict thread matches above, loose matches on Subject: below --
2019-05-02 18:13 simon.zeni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.