Yocto integration

Yocto integration

Hello,

I am trying to use the icc toolchain instead of gcc as a cross-compiler for Yocto, rocko branch.
I followed the documentation and installed the Intel system Studio integration layer on top of poky.

while I only tried to rebuild my project, without any specific call to the icc layer
- that means that I only add the layer to bblayer.conf -
I am facing many issue.

First,

ld  -o libperl.so -L/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib -L/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/lib -Wl,-rpath-link,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/lib -Wl,-rpath,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/lib -Wl,-O1 -shared -L/usr/local/lib op.o     perl.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o   DynaLoader.o -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
| ld: unrecognized option '-Wl,-rpath-link,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib'

Yocto shall not use the host linker,(neither ld itself btw) as far as this one may not have cross compilation features
(with-sysroot).

Looking at `conf/tc-icc.conf`,
the fallback to the "gnu" tool chain overwrites the yocto settings and
define the host compiler instead of the one that yocto will build.

First I comment out "Toolchain=gnu" to fallback to yocto standards.
and then tried to switch to yocto builtins :

` s/HOST_/BUILD_ `

- and insert a space between ld and ${TOOLCHAIN_OPTIONS} -

---
> TOOLCHAIN = 'gnu'
17,22c17,22
< CC_toolchain-gnu = "${CCACHE}${BUILD_PREFIX}gcc ${TOOLCHAIN_OPTIONS} ${BUILD_CC_ARCH}"
< CXX_toolchain-gnu = "${CCACHE}${BUILD_PREFIX}g++ ${TOOLCHAIN_OPTIONS} ${BUILD_CC_ARCH}"
< CPP_toolchain-gnu = "${BUILD_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${BUILD_CC_ARCH}"
< LD_toolchain-gnu = "${BUILD_PREFIX}ld ${TOOLCHAIN_OPTIONS} ${BUILD_LD_ARCH}"
< AR_toolchain-gnu = "${BUILD_PREFIX}ar"
< CCLD_toolchain-gnu = "${BUILD_PREFIX}gcc ${TOOLCHAIN_OPTIONS} ${BUILD_CC_ARCH}"
---
> CC_toolchain-gnu = "${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
> CXX_toolchain-gnu = "${CCACHE}${HOST_PREFIX}g++ ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
> CPP_toolchain-gnu = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
> LD_toolchain-gnu = "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
> AR_toolchain-gnu = "${HOST_PREFIX}ar"
> CCLD_toolchain-gnu = "${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
26,30c26,30
< CC_toolchain-icc  = "icc ${ICC_PREFIX_OPTION}  ${BUILD_CC_ARCH}${TOOLCHAIN_OPTIONS}"
< CXX_toolchain-icc = "icpc ${ICC_PREFIX_OPTION} ${BUILD_CC_ARCH}${TOOLCHAIN_OPTIONS}"
< CPP_toolchain-icc = "icc ${ICC_PREFIX_OPTION} -E${TOOLCHAIN_OPTIONS} ${BUILD_CC_ARCH}"
< LD_toolchain-icc  = "xild ${ICCQ_PREFIX_OPTION} ${TOOLCHAIN_OPTIONS} ${BUILD_LD_ARCH}"
< CCLD_toolchain-icc  = "icc ${ICC_PREFIX_OPTION}  ${BUILD_CC_ARCH}${TOOLCHAIN_OPTIONS}"
---
> CC_toolchain-icc  = "icc ${ICC_PREFIX_OPTION}  ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
> CXX_toolchain-icc = "icpc ${ICC_PREFIX_OPTION} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
> CPP_toolchain-icc = "icc ${ICC_PREFIX_OPTION} -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
> LD_toolchain-icc  = "xild ${ICCQ_PREFIX_OPTION} ${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
> CCLD_toolchain-icc  = "icc ${ICC_PREFIX_OPTION}  ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"

But then, the "fp-model" option is not recognized:

x86_64-pokyads-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1/recipe-sysroot -c -fno-strict-aliasing -fp-model strict  -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1=/usr/src/debug/python/2.7.13-r1 -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1/recipe-sysroot-native= -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1/recipe-sysroot=  -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1=/usr/src/debug/python/2.7.13-r1 -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1/recipe-sysroot-native= -fdebug-prefix-map=/home/marec/bbtmp/icc/tmp/work/corei7-64-pokyads-linux/python/2.7.13-r1/recipe-sysroot=   -I. -IInclude -I../Python-2.7.13/Include  -fPIC -DPy_BUILD_CORE -o Parser/grammar1.o ../Python-2.7.13/Parser/grammar1.c
x86_64-pokyads-linux-gcc: error: strict: No such file or directory
x86_64-pokyads-linux-gcc: error: strict: No such file or directory
x86_64-pokyads-linux-gcc: error: unrecognized command line option '-fp-model'
x86_64-pokyads-linux-gcc: error: unrecognized command line option '-fp-model'

 

Any clue or patch be able to use this layer correctly ?

 

 

publicaciones de 8 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

I found the problem for the second part, the `configure` script detects the use of icc because of the word "icc" in the basename path. So that it appends icc specifics to the CC flags.

 

Now I got issue about redistributable libraries like "libintlc" that are not recognized by yocto as runtime dependencies. It sounds like the recipe for  compiler runtime libraries is missing or not well defined (intel-iss-icc-target ?)

ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libintlc.so.5()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]
ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libsvml.so()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]
ERROR: zlib-1.2.11-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: zlib-1.2.11-r0 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in: /home/marec/bbtmp/studio/tmp/work/corei7-64-poky-linux/zlib/1.2.11-r0/temp/log.do_package_qa.45194
ERROR: Task (/home/marec/poky/meta/recipes-core/zlib/zlib_1.2.11.bb:do_package_qa) failed with exit code '1'

 

 

 

I have another patch that might  be applied:

--- a/classes/tc-secondary.bbclass
+++ b/classes/tc-secondary.bbclass
@@ -27,9 +27,9 @@ python(){
 
        origld = d.getVar("LD_LIBRARY_PATH", True)
        if origld:
-               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/compiler/lib/${ICC_TARGET_ARCH}:")
+               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/lib/${ICC_TARGET_ARCH}:")
        else:
-               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/compiler/lib/${ICC_TARGET_ARCH}")
+               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/lib/${ICC_TARGET_ARCH}")
 
        d.prependVar("PATH", "${ICC_INSTALLDIR}/bin/${ICC_TARGET_ARCH}:")

I guess that the compiler libs have to be somehow set up when using the icc toolchain as either the secondary or primary one .

ERROR: Nothing RPROVIDES 'intel-iss-icc-target' (but /home/marec/poky/wr-iss-2018/recipes-ipp/ippcore/intel-iss-ippcore.bb, /home/marec/poky/meta-payload/recipes-core/images/payload-graphics.bb RDEPENDS on or otherwise requires it)
intel-iss-icc-target was skipped: PREFERRED_PROVIDER_virtual/x86_64-pokyads-linux-compilerlibs set to gcc-runtime, not intel-iss-icc-target
 

Correct this value to "intel-iss-icc-target" sounds ok if one would like to use "icc" as the primary toolchain.

But how to tell bitbake to automatically switch to another compilerlibs provider when using the secondary toolchain ?

 

Is there a better place do discuss about the system-studio yocto layer ? My feelings is that all this feature has not been fully checked out.

 

 

Could you please let me know the following information?

1. The host OS and version.
2. The Intel system studio version. (the latest one is ISS2018 u1 release).
3. What target machine are you building from Yocto rocko?
4. Are you able to build the rocko without the wr-iss-2018 layer?

For the error:
ld: unrecognized option '-Wl,-rpath-link,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib'

Here I think 'ld' is right since you are building the "perl-native". The cross gcc is not used for native receipts. It was built before the cross gcc toolchain is created. You can try:
$bitbake perl-native -c devshell

In the popup console shell, check gcc and ld versions.
On my machine (CentOS host), I have following:
$ which gcc
/yocto_project/poky-rocko-18.0.0/poky/build_qemux86_64-2/tmp/hosttools/gcc
$ which ld
/yocto_project/poky-rocko-18.0.0/poky/build_qemux86_64-2/tmp/hosttools/ld
$ ld --version
GNU ld version 2.25.1-22.base.el7
...
$ cd /yocto_project/poky-rocko-18.0.0/poky/build_qemux86_64-2/tmp/hosttools/
$ ls gcc ld -l
 Apr 27 09:56 gcc -> /usr/bin/gcc
 Apr 27 09:56 ld -> /usr/bin/ld

Here you can see that both gcc and ld are symbolic to the host gcc/ld.

With a fresh build without the wr-iss-2018 enabled, from log.do_compile file, I can see that the native gcc and ld are used to build the perf-native.
And if you are building the "perl" for the target, e.g. bitbake perl, you can find from the log.do_compile file that the cross gcc compiler is used.

I would suggest to check first if you can build the same without the wr-iss-2018 layer. If it works fine, then to enable the wr-iss-2018 layer.

Thanks.

-Yang
 

 

For the issue in the file tc-secondary.bbclass:

-               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/compiler/lib/${ICC_TARGET_ARCH}:")
+               d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/lib/${ICC_TARGET_ARCH}:")

This is a good catch. The path should be changed.
We will fix it in the future release.
However in general this should not be a problem as the icc compiler now can automatically find the runtime libraries.

For the issue:
ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libintlc.so.5()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]
ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libsvml.so()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]

Please add the following in the zlib*.bb recipes file if you are using icc to build zlib:
RDEPENDS_${PN}+="intel-iss-icc-target"
Or add the following in the local.conf so the icc runtime can be built into the target image.
IMAGE_INSTALL_append = " intel-iss-icc-target"

Thanks.

-Yang

Cita:

yang-wang (Intel) escribió:

Could you please let me know the following information?

1. The host OS and version.

CentOS Linux release 7.4.1708 (Core)

Cita:


2. The Intel system studio version. (the latest one is ISS2018 u1 release).

If have to make sure about the PR, but it's 2018.

Cita:

3. What target machine are you building from Yocto rocko?

intel-core-i7

Cita:


4. Are you able to build the rocko without the wr-iss-2018 layer?

Yes.

 

Cita:

For the error:
ld: unrecognized option '-Wl,-rpath-link,/home/marec/bbtmp/icc/tmp/work/x86_64-linux/perl-native/5.24.1-r0/recipe-sysroot-native/usr/lib'

Here I think 'ld' is right since you are building the "perl-native". The cross gcc is not used for native receipts. It was built before the cross gcc toolchain is created.

 

No, It should not, see the `perl-native` recipes:

export LD="${CCLD}"

This works if the toolchain is not redefined for this recipe (or set to `gcc`). See `tc-per-package`

TOOLCHAIN_pn-perl-native = 'gnu'

 

Cita:

You can try:
$bitbake perl-native -c devshell

$ ld --version
GNU ld version 2.25.1-22.base.el7

without "icc" layer:

$ echo $LD
gcc

With icc layer (gnu toolchain)

echo $LD
ld

Cita:

 I would suggest to check first if you can build the same without the wr-iss-2018 layer. If it works fine, then to enable the wr-iss-2018 layer.

Yocto builds the image successfully without the icc-layer. I append this layer on top of a existing project.

 

 

Cita:

yang-wang (Intel) escribió:

However in general this should not be a problem as the icc compiler now can automatically find the runtime libraries.

You are right, it seem to works even with a wrong LD_LIBRARY_PATH. Dunno where the magic wand applies. Anyway, this means that the whole function might be removed ? (To avoid annoying the recipe parser with this )

Cita:

For the issue:
ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libintlc.so.5()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]
ERROR: zlib-1.2.11-r0 do_package_qa: QA Issue: /lib/libz.so.1.2.11 contained in package zlib requires libsvml.so()(64bit), but no providers found in RDEPENDS_zlib? [file-rdeps]

Please add the following in the zlib*.bb recipes file if you are using icc to build zlib:
RDEPENDS_${PN}+="intel-iss-icc-target"

This has to be done for any recipe to be built with icc.

As an example, png:

/home/marec/bbtmp/studio/tmp/work/corei7-64-pokyads-linux/libpng/1.6.31-r0/recipe-sysroot-native/usr/bin/x86_64-pokyads-linux/../../libexec/x86_64-pokyads-linux/gcc/x86_64-pokyads-linux/7.3.0/ld: warning: libintlc.so.5, needed by /home/marec/bbtmp/studio/tmp/work/corei7-64-pokyads-linux/libpng/1.6.31-r0/recipe-sysroot/usr/lib/../lib/libz.so, not found (try using -rpath or -rpath-link)
/home/marec/bbtmp/studio/tmp/work/corei7-64-pokyads-linux/libpng/1.6.31-r0/recipe-sysroot-native/usr/bin/x86_64-pokyads-linux/../../libexec/x86_64-pokyads-linux/gcc/x86_64-pokyads-linux/7.3.0/ld: warning: libsvml.so, needed by /home/marec/bbtmp/studio/tmp/work/corei7-64-pokyads-linux/libpng/1.6.31-r0/recipe-sysroot/usr/lib/../lib/libz.so, not found (try using -rpath or -rpath-link)

`libz.so` exists in `sysroot`, but failed to be validated by the configuration script failed, - ( it compiles at once a short program that links to libz  ) -, while icc runtime libraries can't be reached at that time.

I tried to solve this by appending the intel-iss-icc-target as a base dependency, for icc tool-chain first and also for all. But I hit circular dependencies, conflicts between icc redistributables and gcc libs...

 

# SET INHIBIT_ICC_TARGET to "1" into intel-iss-icc-target
def icc_dep_prepend(d):
        if d.getVar('INHIBIT_ICC_TARGET_DEPS', False):
                return ""
        return " intel-iss-icc-target"

#BASEDEPENDS_append = "${@icc_dep_prepend(d)}"
BASEDEPENDS_append_toolchain-icc_class-target = "${@icc_dep_prepend(d)}"

 

Cita:

Or add the following in the local.conf so the icc runtime can be built into the target image.
IMAGE_INSTALL_append = " intel-iss-icc-target"

Correct me if I m wrong, this will add the runtime libraries into the final image, but not into any recipe sysroot for building.

 

 

Cita:

TurtleCrazy escribió:

I tried to solve this by appending the intel-iss-icc-target as a base dependency, for icc tool-chain first and also for all. But I hit circular dependencies, conflicts between icc redistributables and gcc libs...

 

Finally, adding a dependency for building (DEPENDS) is the only solution I found. To automatically append to recipes to be build by icc , here are the patches:

--- b/classes/tc-secondary.bbclass 2018-04-30 09:38:38.803811526 +0200
+++ a/classes/tc-secondary.bbclass 2018-05-03 13:29:28.597311068 +0200
@@ -27,9 +27,9 @@
 
  origld = d.getVar("LD_LIBRARY_PATH", True)
  if origld:
-  d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/compiler/lib/${ICC_TARGET_ARCH}:")
+  d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/lib/${ICC_TARGET_ARCH}:")
  else:
-  d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/compiler/lib/${ICC_TARGET_ARCH}")
+  d.prependVar("LD_LIBRARY_PATH","${ICC_INSTALLDIR}/lib/${ICC_TARGET_ARCH}")
 
  d.prependVar("PATH", "${ICC_INSTALLDIR}/bin/${ICC_TARGET_ARCH}:")
 
--- b/conf/tc-icc.conf 2018-04-30 09:38:38.986811519 +0200
+++ a/conf/tc-icc.conf 2018-05-03 13:29:30.877310980 +0200
@@ -8,10 +8,11 @@
 
 # You can enable per package build by icc using TOOLCHAIN_pn-yourpackagename='icc'
 # For example, in file conf/tc-per-package.conf or your package .bb file
-#TOOLCHAIN_pn-gzip = 'icc'
+TOOLCHAIN_pn-gzip = 'icc'
 
 # Define the Per package list file to specify the toolchain by package
 include conf/tc-per-package.conf
+DEPENDS_append_toolchain-icc = " virtual/TOOLCHAIN-ICC"
 
 # Override values for gnu:
 CC_toolchain-gnu = "${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
@@ -28,5 +29,6 @@
 CPP_toolchain-icc = "icc ${ICC_PREFIX_OPTION} -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
 LD_toolchain-icc  = "xild ${ICCQ_PREFIX_OPTION} ${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
 CCLD_toolchain-icc  = "icc ${ICC_PREFIX_OPTION}  ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-AR_toolchain-icc = "xiar ${ICCQ_PREFIX_OPTION}"
+#AR_toolchain-icc = "xiar ${ICCQ_PREFIX_OPTION}"
+AR_toolchain-icc = "${HOST_PREFIX}ar"
 
diff -ur b/conf/tc-per-package.conf a/conf/tc-per-package.conf
--- b/conf/tc-per-package.conf 2018-04-30 09:38:38.986811519 +0200
+++ a/conf/tc-per-package.conf 2018-05-03 13:41:21.483283653 +0200
@@ -1,7 +1,8 @@
 # Per package toolchain configuration
 # specify the icc build package here:
-#TOOLCHAIN_pn-gzip = 'icc'
-#TOOLCHAIN_pn-zlib = 'icc'
+#
+TOOLCHAIN_pn-gzip = 'icc'
+TOOLCHAIN_pn-zlib = 'icc'
 
 #enable the default gnu build for the following packages
 TOOLCHAIN_pn-pseudo-native = 'gnu'
@@ -9,7 +10,7 @@
 TOOLCHAIN_pn-elfutils-native = 'gnu'
 TOOLCHAIN_pn-binutils-native = 'gnu'
 TOOLCHAIN_pn-libffi-native = 'gnu'
-TOOLCHAIN_pn-perl-native = 'gnu'
+TOOLCHAIN_pn-perl-native = 'gcc'
 TOOLCHAIN_pn-cross-localedef-native = 'gnu'
 TOOLCHAIN_pn-pixman-native = 'gnu'
 TOOLCHAIN_pn-qemu-native = 'gnu'

 --- b/recipes-icc/intel-iss-icc-target/intel-iss-icc-target_17.0.bb 2018-04-30 09:38:39.287811508 +0200
+++ a/recipes-icc/intel-iss-icc-target/intel-iss-icc-target_17.0.bb 2018-05-03 13:44:35.856276178 +0200
@@ -8,6 +8,7 @@
 
 DEPENDS=""
 RDEPENDS_${PN}=""
+PROVIDES += "virtual/TOOLCHAIN-ICC"
 
 #PR = "r0"
 
@@ -33,6 +34,8 @@
 #If your application don't need all the libraries:
 # 1. you can install the selected runtime libraries into your application specific folder
 # 2. you can install the selected runtime libraries into system folder
+BBCLASSEXTEND = " native nativesdk"
+RUNTIMETARGET = "libintlc libirc libsvml libgfxoffload libimf libirng libcilkrts"
 do_install() { 
  mkdir -p ${D}/${libdir}
  if [ "x86_64" = "${TARGET_ARCH}" ] ; then 
@@ -42,7 +45,11 @@
      icc_arch=ia32; 
      target_lib=lib; 
  fi; 
- cp -r ${icc_base}/lib/${icc_arch}_lin/*.so*  ${D}/${libdir}
- rm -f ${D}/${libdir}/libioffload_target*
+ install -d ${D}${libdir} 
+ for d in ${RUNTIMETARGET}; do
+  install -m 0444  ${icc_base}/lib/${icc_arch}_lin/${d}*.so* ${D}${libdir}/
+ done
+
+ rm -f ${D}${libdir}/libioffload_target*
 }
 

There is still some work to make CMake happy with  icc in yocto 's  toolchain.cmake. Due to a regex  expression that shortens the compiler settings in cmake.bbclass,  the gnu prefix needed by ICC is lost; and that's also why I do not use the static libraries  "ARchiver" from icc.

 

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya