Thanks for the response.

Is the PREFERRED_PROVIDER_virtual/kernel set to linux-yocto? You need
to set the PREFERRED_VERSION for kernel that you are using ...

Yes, I tried to set both in local.conif or distro, none of works.

bitbake -e virtual/kernel output should help see how it's being set and
where.

There was no PREFERRED_PROVIDER_virtual/kernel, nor
PREFERRED_VERSION_linux-yocto setup.

Thank you.

Kind regards,

- j

On Wed, 2021-01-06 at 17:02 +1100, JH wrote:

Hi,

I replaced Linux kernel version from 4.19 by 5.10 bb file, but it
still built 4.19 zImage, I add PREFERRED_VERSION_linux-yocto =
"5.10%"
in local.conf, it still built 4.19 zImage. Where the linux kernel
version is defined in configure files?

Is the PREFERRED_PROVIDER_virtual/kernel set to linux-yocto? You need
to set the PREFERRED_VERSION for kernel that you are using ...

bitbake -e virtual/kernel output should help see how it's being set and
where.

Thanks,

Anuj

Hi,

I replaced Linux kernel version from 4.19 by 5.10 bb file, but it
still built 4.19 zImage, I add PREFERRED_VERSION_linux-yocto = "5.10%"
in local.conf, it still built 4.19 zImage. Where the linux kernel
version is defined in configure files?

Thank you.

Kind regards,

- j

On Mon, 2021-01-04 at 11:44 +0100, Konrad Weihmann wrote:

I have a bunch of custom testcases (oeqa/runtime/cases) which are
interacting with "d" from the build host - basically fetching some
info
while executing the test, e.g.

foo = self.tc.td['MY_CUSTOM_VAR']

What I've seen is that these files create python __pycache__ files
during parsing of the testimage run.

On the initial run everything is working like expected, but if I now
change the variable "MY_CUSTOM_VAR", without modifying the
target-filesystem the value inside the test case doesn't get updated.

Did anyone else encountered this?

To me it seems like the value of the var does make it into the
pycache
files, ignoring the updated value on a second run.

On that note: wouldn't it make sense to disable the cache creation
for
oeqa test cases? just to mitigate chances of such scenarios?

Or maybe I'm doing something wrong here, so any pointers are highly
appreciated.

FWIW this doesn't sound right to me. pyc files (in __pycache__) would
cache the code, not data so I don't see how these values would be
preserved there. I don't doubt you're seeing some kind of issue but I
suspect its more likely bitbake's cache or something...

Cheers,

Richard

On Sun, 2021-01-03 at 10:44 -0800, Paul D. DeRocco wrote:
I've been resurrecting an old Pyro project under Gatesgarth. It's an
Intel
32-bit system that needs maximum speed, so I decided to try to build
the
system and application as 64-bit, for more registers. It pretty much
worked
on the first try, and is about 8% faster. Now I'm trying to do it as
x32, to
see if that speeds it up even more.

Unable to find any specific instructions, I set the DEFAULTTUNE to
"core2-64-x32" in my BSP conf file. Also, in the old project I had
tinkered
around with this a bit, and had found some kernel config settings
somewhere,
so I tried using them again:

CONFIG_X86_X32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_BLOCK_COMPAT=y

Other than the first one, I don't know whether these are correct, or
where I
originally got them, or if there's a stock .cfg file that does all
this.

The system built fine, the SDK built fine, and my application built
fine,
but when I boot, I get a kernel panic, preceded by some message about
"kmod
busy with 50 threads for more than 5 seconds now".

Is there some instruction on how to do a proper x32 build? I couldn't
find
one Googling. Barring that, do any of those kernel configs look bogus?

You can see the autobuilder x32 test configuration here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/2866/steps/10/logs/stdio

the key parts of which are probably:

MACHINE = "qemux86-64"
DEFAULTTUNE = 'x86-64-x32'
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"

Cheers,

Richard

Hi,

Where to download Yocto receipt for kernel version 5.10? To update a
stable version, should I update Yocto version to 3.3 or 3.1?

Thank you.

Kind regards,

- j

* add support for mingw32
* Engines are installed in a slightly different path, which is
urgly, patch it to make the path shorter
* remove runtime dependency from perl for mingw nativesdk

since commit 70da1f956bfbb627691c47eba7451182aca758e3 of oe-core
'openssl: Add c_rehash to misc package and add perl runtime dependency'

package openssl-misc have runtime dependency on perl, and perl then
have depenency on another 3 recipes, db/gdbm/libxcrypt. according to
http://arsv.github.io/perl-cross/usage.html, perl don't support
cross-compile build for mingw32 and another 3 recipes also don't
support mingw well. so remove the dependency of perl, don't support
c_rehash for mingw.

Signed-off-by: Changqing Li <changqing.li@...>
---
...ile.tmpl-don-t-add-prefix-for-libdir.patch | 32 +++++++++++++++++++
.../openssl/openssl_%.bbappend | 31 ++++++++++++++++++
2 files changed, 63 insertions(+)
create mode 100644 recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
create mode 100644 recipes-connectivity/openssl/openssl_%.bbappend

diff --git a/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
new file mode 100644
index 0000000..028431b
--- /dev/null
+++ b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
@@ -0,0 +1,32 @@
+From 8fe5c9421acfaff35b637e7ad55d1df598bb7081 Mon Sep 17 00:00:00 2001
+From: Changqing Li <changqing.li@...>
+Date: Tue, 22 Dec 2020 09:22:10 +0800
+Subject: [PATCH] unix-Makefile.tmpl: don't add prefix for libdir
+
+we had pass libdir to Configure, don't use prefix again to
+avoid engineer dir set to:
+/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/lib/engines-1_1
+
+Upstream-Status: Inappropriate[oe-specific]
+
+Signed-off-by: Changqing Li <changqing.li@...>
+---
+ Configurations/unix-Makefile.tmpl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Configurations/unix-Makefile.tmpl b/Configurations/unix-Makefile.tmpl
+index bbafb98..eecb63e 100644
+--- a/Configurations/unix-Makefile.tmpl
++++ b/Configurations/unix-Makefile.tmpl
+@@ -244,7 +244,7 @@ LIBDIR={- our $libdir = $config{libdir} || "lib";
+ File::Spec::Win32->file_name_is_absolute($libdir) ? "" : $libdir -}
+ ENGINESDIR_dev={- use File::Spec::Win32;
+ our $enginesdir =
+- File::Spec::Win32->catdir($prefix,$libdir,
++ File::Spec::Win32->catdir($libdir,
+ "engines-$sover_dirname");
+ our ($enginesdir_dev, $enginesdir_dir, $enginesdir_file) =
+ File::Spec::Win32->splitpath($enginesdir, 1);
+--
+2.17.1
+
diff --git a/recipes-connectivity/openssl/openssl_%.bbappend b/recipes-connectivity/openssl/openssl_%.bbappend
new file mode 100644
index 0000000..7fd82f1
--- /dev/null
+++ b/recipes-connectivity/openssl/openssl_%.bbappend
@@ -0,0 +1,31 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+SRC_URI_append_mingw32_class-nativesdk = " \
+ file://0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch \
+"
+
+do_configure_mingw32 () {
+ os=${HOST_OS}
+ target="$os-${HOST_ARCH}"
+ case $target in
+ mingw32-x86_64)
+ target=mingw64
+ ;;
+ mingw32-i686)
+ target=mingw
+ ;;
+ esac
+
+ useprefix=${prefix}
+ if [ "x$useprefix" = "x" ]; then
+ useprefix=/
+ fi
+ # WARNING: do not set compiler/linker flags (-I/-D etc.) in EXTRA_OECONF, as they will fully replace the
+ # environment variables set by bitbake. Adjust the environment variables instead.
+ HASHBANGPERL="/usr/bin/env perl" PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
+ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target
+ perl ${B}/configdata.pm --dump
+}
+
+FILES_${PN}-engines_mingw32_class-nativesdk = "${libdir}/engines-1_1"
+RDEPENDS_${PN}-misc_remove_mingw32_class-nativesdk = "perl"
--
2.17.1

On Mon, 4 Jan 2021 at 10:50, Konrad Weihmann <kweihmann@...> wrote:

I have a few oeqa test cases, which always should run last in a test
suite (log and file collectors for instance).

Those are not test cases then, surely. If you want to run actions
after test cases to collect log files then I'd implement that as a
decorator on the test cases.

Ross

Other than the first one, I don't know whether these are correct, or
where I
originally got them, or if there's a stock .cfg file that does all
this.

I'm not familiar with x32 myself but Debian has an x32port which should
give you a working kernel config to start from.
https://wiki.debian.org/X32Port


--

<http://holoplot.com/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>

<https://holoplot.com/>*HOLOPLOT GmbH - Headquarters*


Ringbahnstr. 12
(10-14) / A2

12099 Berlin, Germany

+49 (0) 30 40745812




*HOLOPLOT GmbH
- Manufacturing*


Alboinstr. 17-23 / Hall 12

12103 Berlin, Germany

+49
(0) 30 959988740


www.holoplot.com <https://holoplot.com/>



Follow us on
<https://www.facebook.com/OriginalHOLOPLOT/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>
LinkedIn
<https://www.linkedin.com/company/holoplot-gmbh?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>.




Roman Sick – CEO | HRB183974B, Register Court Charlottenburg, Germany |
EU Tax-Registration No. DE277000701 This e-mail contains confidential
and/or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the information in this e-mail is strictly forbidden.

Hi all,

I have a few oeqa test cases, which always should run last in a test suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those tests like "zzz_<name>" to move them to the end of the computed list.

Unfortunately this is very error prone, as the OETestDepends tag does have major influence on the ordering (just a single misplaced tag in any test case can make it past those "zzz" cases).
Also it makes things hard to read IMO.

That brings me to my question, is there any way to ensure that test cases are run at the end of the complete list of test suites?

If not does anyone have an idea how to create such a feature (maybe a new decorator or something like that)?

Regards
Konrad

Hi all,

I have a bunch of custom testcases (oeqa/runtime/cases) which are interacting with "d" from the build host - basically fetching some info while executing the test, e.g.

foo = self.tc.td['MY_CUSTOM_VAR']

What I've seen is that these files create python __pycache__ files during parsing of the testimage run.

On the initial run everything is working like expected, but if I now change the variable "MY_CUSTOM_VAR", without modifying the target-filesystem the value inside the test case doesn't get updated.

Did anyone else encountered this?

To me it seems like the value of the var does make it into the pycache files, ignoring the updated value on a second run.

On that note: wouldn't it make sense to disable the cache creation for oeqa test cases? just to mitigate chances of such scenarios?

Or maybe I'm doing something wrong here, so any pointers are highly appreciated.

Regards
Konrad

Hi Hongxu,

On Wed, Dec 16, 2020 at 2:09 PM Hongxu Jia <hongxu.jia@...> wrote:

Signed-off-by: Hongxu Jia <hongxu.jia@...>
---
.../0001-customize-for-yocto.patch | 28 +++++++++++++++++++
.../tensorflow/tensorflow-estimator_1.13.bb | 12 ++++++--
2 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch

diff --git a/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
new file mode 100644
index 0000000..e9b66d5
--- /dev/null
+++ b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
@@ -0,0 +1,28 @@
+From a1bcf09a43fc44ad5e04c441ee45cc23d16cf7d2 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@...>
+Date: Wed, 9 Dec 2020 17:59:01 +0800
+Subject: [PATCH] customize for yocto
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia <hongxu.jia@...>
+---
+ tensorflow_estimator/tools/pip_package/build_pip_package.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tensorflow_estimator/tools/pip_package/build_pip_package.sh b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+index d4953a6..e08cd8a 100755
+--- a/tensorflow_estimator/tools/pip_package/build_pip_package.sh
++++ b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+@@ -38,7 +38,7 @@ function prepare_src() {
+
+ # Verifies all expected files are in pip.
+ # Creates init files in all directory in pip.
+- python tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
++ nativepython3 tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
+ }
+
+ function build_wheel() {
+--
+2.18.2
+
diff --git a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
index f3a5098..5b2fe5d 100644
--- a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
+++ b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
@@ -3,9 +3,10 @@ learning programming."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=01e86893010a1b87e69a213faa753ebd"

-SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r1.13 \
+SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.4 \
+ file://0001-customize-for-yocto.patch \
"
-SRCREV = "340703eed78ba4854862f749ed94f91598826e79"
+SRCREV = "c3e7f2b5bbcc35185ef71797955a28cadce28f60"
S = "${WORKDIR}/git"

inherit python3native bazel
@@ -19,12 +20,18 @@ DEPENDS += " \
python3-astor-native \
python3-gast-native \
python3-termcolor-native \
+ python3-wrapt-native \
+ python3-opt-einsum-native \
+ python3-astunparse-native \
+ flatbuffers-native \

I'm getting issue when building tensorflow-estimator (I add small
changes to be able to build this patches on top of dunfell) and I'm
getting:
| /bin/bash -c 'source
external/bazel_tools/tools/genrule/genrule-setup.sh;
bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1
--apidir=bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api_v1/
--apiname=estimator --apiversion=1
--package=tensorflow_estimator.python.estimator
--output_package=tensorflow_estimator.python.estimator.api._v1
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/v1.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/experimental/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/export/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/inputs/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/experimental/__init__.py')
| Execution platform: @local_config_platform//:host
| /home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/h5py/__init__.py:72:
UserWarning: h5py is running against HDF5 1.8.21 when it was built
against 1.8.19, this may cause problems
| _warn(("h5py is running against HDF5 {0} when it was built against {1}, "
| Traceback (most recent call last):
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/api/create_python_api_wrapper.py",
line 26, in <module>
| from tensorflow_estimator.python.estimator import estimator_lib
# pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/estimator_lib.py",
line 22, in <module>
| from tensorflow_estimator.python.estimator.canned.baseline
import BaselineClassifier
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/canned/baseline.py",
line 53, in <module>
| import tensorflow as tf
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/__init__.py",
line 55, in <module>
| from ._api.v2 import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/__init__.py",
line 34, in <module>
| from . import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/v1/__init__.py",
line 51, in <module>
| from tensorflow._api.v2.compat.v1 import lite
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/__init__.py",
line 11, in <module>
| from . import experimental
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/__init__.py",
line 10, in <module>
| from . import nn
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/nn/__init__.py",
line 10, in <module>
| from tensorflow.lite.python.lite import TFLiteLSTMCell
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/lite.py",
line 40, in <module>
| from tensorflow.lite.python.convert import
build_toco_convert_protos # pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/convert.py",
line 33, in <module>
| from tensorflow.lite.python import util
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/util.py",
line 30, in <module>
| import flatbuffers
| ModuleNotFoundError: No module named 'flatbuffers'

FLatbuffers from openembedded are available version 1.12. Do you have
an idea what is can cause?

tensorflow-native \
"

do_compile () {
unset CC
export TMPDIR="${WORKDIR}"
+ export PYTHON_BIN_PATH="${PYTHON}"
+
${BAZEL} build \
--subcommands --explain=${T}/explain.log \
--verbose_explanations --verbose_failures \
@@ -32,7 +39,6 @@ do_compile () {
--python_path="${PYTHON}" \
//tensorflow_estimator/tools/pip_package:build_pip_package

- PYTHON_BIN_PATH="${PYTHON}" \
${S}/bazel-bin/tensorflow_estimator/tools/pip_package/build_pip_package \
${WORKDIR}/estimator_pip
}
--
2.21.0

Thanks and BR,

marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

From: Paul D. DeRocco

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm
getting this compile error when I use the SDK to separately compile my
application. I get no such errors when I build Linux, or the SDK.

In file included from

/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453

,
from

/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465,

from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/dirent.h:25,
from ../my_header_file.h:7,
from ../my_source_file.cpp:3:

/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/bits/long-doubl

e.h:23:10: fatal error: bits/long-double-32.h: No such file
or directory

etc., etc.

I solved this myself by building an SDK specific to the x32 configuration,
rather than trying to use the plain 64-bit SDK. What led me to believe that
the 64-bit SDK should work is that the host sysroot includes
/usr/bin/x86_64-poky-linux and /usr/bin/x86_64-poky-linux-gnux32
subdirectories. The latter contains symlinks into the former, which is no
surprise, since one toolchain should be able to do 32, 64, and 64x32, but
the target sysroot include files don't quite work. The only reason I care is
that each SDK is about 2.4GB. So I'm not sure if this is a bug, or whose bug
it is, but 2.4GB seems awfully large for an SDK, especially since this is
the standard SDK, not the ESDK.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...