from:"baisch"

[yocto] Yocto update to Sumo with Multilib results in error in do_image_wic

2018-05-25 Thread baisch

After the update to Yocto 2.5 Sumo my genericx86 build doesn't work anymore. 
The problem seems to be with the Multilib feature. I need the 64 bit version of 
grub-efi so I've added this to my local.conf:

  require conf/multilib.conf
  MULTILIBS = "multilib:lib64"
  DEFAULTTUNE_virtclass-multilib-lib64 = "x86-64"
  IMAGE_INSTALL_append = " lib64-grub-efi"

With Sumo I get this error:

  image-dev-1.0-r0 do_image_wic: Error executing a python function in 
exec_python_func() autogenerated:

  […]

  Subprocess output:
  sed: can't read 
/workdir/poky/build-x86/tmp/work/genericx86-poky-linux/image-dev/1.0-r0/recipe-sysroot/usr/bin/crossscripts/x86_64-pokymllib64-linux-libtool:
 No such file or directory

The file `x86_64-pokymllib64-linux-libtool` is in 
`genericx86-pokymllib64-linux/image-dev/1.0-r0/lib64-recipe-sysroot/usr/bin/crossscripts/`
 (Note the difference: `lib64`). If I copy it over just to see what happens, 
another error pops up:

  ERROR: image-dev-1.0-r0 do_image_wic: Error executing a python function in 
exec_python_func() autogenerated:

  […]

  Exception: FileExistsError: [Errno 17] File exists: 
'/workdir/poky/build-x86/tmp/sysroots-components/x86_64/lib64-glibc/sysroot-providers/virtual_lib64-libc'
 -> 
'/workdir/poky/build-x86/tmp/work/genericx86-pokymllib64-linux/image-dev/1.0-r0/lib64-recipe-sysroot/sysroot-providers/virtual_lib64-libc'

  ERROR: image-dev-1.0-r0 do_image_wic: Function failed: extend_recipe_sysroot

Did something fundamentally change with Multilib in Sumo? I scanned the manual 
but it seems that I don't have to do anything different than before. 
https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#using-multilib

When I comment the Multilib lines from the local.config it builds without 
errors.

For the full python stack trace see this post: 
https://stackoverflow.com/questions/50470148/yocto-update-to-sumo-with-multilib-results-in-error-in-do-image-wic

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto update to Sumo with Multilib results in error in do_image_wic

2018-06-23 Thread baisch

bai...@tau-tec.com wrote on 25.05.2018 14:16:
> After the update to Yocto 2.5 Sumo my genericx86 build doesn't work
> anymore. The
> problem seems to be with the Multilib feature. I need the 64 bit version
> of
> grub-efi so I've added this to my local.conf:
> 
>   require conf/multilib.conf
>   MULTILIBS = "multilib:lib64"
>   DEFAULTTUNE_virtclass-multilib-lib64 = "x86-64"
>   IMAGE_INSTALL_append = " lib64-grub-efi"
> 
> With Sumo I get this error:
> 
>   image-dev-1.0-r0 do_image_wic: Error executing a python function in
>   exec_python_func() autogenerated:
> 
>   […]
> 
>   Subprocess output:
>   sed: can't read
>   
> /workdir/poky/build-x86/tmp/work/genericx86-poky-linux/image-dev/1.0-r0/recipe-sysroot/usr/bin/crossscripts/x86_64-pokymllib64-linux-libtool:
>   No such file or directory
> 
> The file `x86_64-pokymllib64-linux-libtool` is in
> `genericx86-pokymllib64-linux/image-dev/1.0-r0/lib64-recipe-sysroot/usr/bin/crossscripts/`
> (Note the difference: `lib64`). If I copy it over just to see what
> happens,
> another error pops up:
> 
>   ERROR: image-dev-1.0-r0 do_image_wic: Error executing a python function
>   in
>   exec_python_func() autogenerated:
> 
>   […]
> 
>   Exception: FileExistsError: [Errno 17] File exists:
>   
> '/workdir/poky/build-x86/tmp/sysroots-components/x86_64/lib64-glibc/sysroot-providers/virtual_lib64-libc'
>   ->
>   
> '/workdir/poky/build-x86/tmp/work/genericx86-pokymllib64-linux/image-dev/1.0-r0/lib64-recipe-sysroot/sysroot-providers/virtual_lib64-libc'
> 
>   ERROR: image-dev-1.0-r0 do_image_wic: Function failed:
>   extend_recipe_sysroot
> 
> Did something fundamentally change with Multilib in Sumo? I scanned the
> manual
> but it seems that I don't have to do anything different than before.
> https://www.yoctoproject.org/docs/2.5/mega-manual/mega-manual.html#using-multilib
> 
> When I comment the Multilib lines from the local.config it builds without
> errors.
> 
> For the full python stack trace see this post:
> https://stackoverflow.com/questions/50470148/yocto-update-to-sumo-with-multilib-results-in-error-in-do-image-wic
> 
>


Hello,

I wanted to ask if anyone had an idea for an alternative solution to the 
original problem.
We need the system to be 32bit. But the bios on the hardware expects a 64bit 
bootloader. 
So the machine type is set to `genericx86`, and now I've added the 64bit 
version of grub with the Multilib feature.
Since this is not working anymore in Sumo, my question is, if anyone knows 
another maybe even better/more elegant way 
to solve this problem? Or alternatively how to fix this in Sumo.

Regards,
Michael



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] SDK: getting error "xmlcatalog: not found" installing SDK

2019-07-30 Thread baisch

Hello,

after updating to warrior 2.7.1 from thud and trying to install the Extensible 
SDK again I'm getting the following error:

```
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_build_native_sysroot(d)
 0003:
File: '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb', 
lineno: 23, function: do_build_native_sysroot
 0019:
 0020:python do_build_native_sysroot () {
 0021:targetsysroot = d.getVar("STANDALONE_SYSROOT")
 0022:nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
 *** 0023:staging_populate_sysroot_dir(targetsysroot, nativesysroot, True, 
d)
 0024:}
 0025:do_build_native_sysroot[cleandirs] = "${STANDALONE_SYSROOT_NATIVE}"
 0026:do_build_native_sysroot[nostamp] = "1"
 0027:addtask do_build_native_sysroot before do_build
File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno: 235, 
function: staging_populate_sysroot_dir
 0231:continue
 0232:
 0233:staging_processfixme(fixme, targetdir, targetsysroot, 
nativesysroot, d)
 0234:for p in postinsts:
 *** 0235:subprocess.check_output(p, shell=True, 
stderr=subprocess.STDOUT)
 0236:
 0237:#
 0238:# Manifests here are complicated. The main sysroot area has the 
unpacked sstate
 0239:# which us unrelocated and tracked by the main sstate manifests. Each 
recipe
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 395, function: check_output
 0391:# empty string. That is maintained here for backwards 
compatibility.
 0392:kwargs['input'] = '' if kwargs.get('universal_newlines', 
False) else b''
 0393:
 0394:return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
 *** 0395:   **kwargs).stdout
 0396:
 0397:
 0398:class CompletedProcess(object):
 0399:"""A process that has finished running.
File: 
'/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
 lineno: 487, function: run
 0483:raise
 0484:retcode = process.poll()
 0485:if check and retcode:
 0486:raise CalledProcessError(retcode, process.args,
 *** 0487: output=stdout, stderr=stderr)
 0488:return CompletedProcess(process.args, retcode, stdout, stderr)
 0489:
 0490:
 0491:def list2cmdline(seq):
Exception: subprocess.CalledProcessError: Command 
'/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
 returned non-zero exit status 127.

Subprocess output:
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 5: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 8: 
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
 xmlcatalog: not found
```

I believe the problem is that in the 
`postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not an 
absolute path and thus not found.
This can be traced to the new `layers/poky/meta/classes/xmlcatalog.bbclass`. I 
tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog` there, 
but even after cleaning the `docbook-xsl-stylesheets` recipe this change had no 
effect. I'm not sure if this class is cached somewhere else or something.

Can someone help me getting the SDK to work again, and maybe this is general 
thing with needs to be fixed?


Thank you.

Regards,

- Michael
-- 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SDK: getting error "xmlcatalog: not found" installing SDK

2019-08-09 Thread baisch

Hello everyone,

I was able to workaround this issue: 

In `conf/bblayers.conf` I put my custom layer ontop of the `meta` layer. Since 
classes seem to ignore the priority set by the layer config. Then I copied the 
`classes/xmlcatalog.bbclass` class to my layer and in the file I changed 
`xmlcatalog` to `${bindir}/xmlcatalog`.

I'm still not sure if this an error specific to my setup or a general issue 
which should be fixed. Also I was hoping there is a better solution since 
changes to the original `classes/xmlcatalog.bbclass` will always be overridden.

Regards,

- Michael
-- 


bai...@tau-tec.com wrote on 30.07.2019 16:32:
> Hello,
> 
> after updating to warrior 2.7.1 from thud and trying to install the
> Extensible
> SDK again I'm getting the following error:
> 
> ```
> ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Error executing a
> python
> function in exec_python_func() autogenerated:
> 
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:do_build_native_sysroot(d)
>  0003:
> File:
> '/workdir/sdk/rpi/layers/poky/meta/recipes-core/meta/build-sysroots.bb',
> lineno: 23, function: do_build_native_sysroot
>  0019:
>  0020:python do_build_native_sysroot () {
>  0021: targetsysroot = d.getVar("STANDALONE_SYSROOT")
>  0022: nativesysroot = d.getVar("STANDALONE_SYSROOT_NATIVE")
>  *** 0023: staging_populate_sysroot_dir(targetsysroot, nativesysroot,
>  True, d)
>  0024:}
>  0025:do_build_native_sysroot[cleandirs] =
>  "${STANDALONE_SYSROOT_NATIVE}"
>  0026:do_build_native_sysroot[nostamp] = "1"
>  0027:addtask do_build_native_sysroot before do_build
> File: '/workdir/sdk/rpi/layers/poky/meta/classes/staging.bbclass', lineno:
> 235,
> function: staging_populate_sysroot_dir
>  0231: continue
>  0232:
>  0233: staging_processfixme(fixme, targetdir, targetsysroot,
>  nativesysroot, d)
>  0234: for p in postinsts:
>  *** 0235: subprocess.check_output(p, shell=True,
>  stderr=subprocess.STDOUT)
>  0236:
>  0237:#
>  0238:# Manifests here are complicated. The main sysroot area has the
>  unpacked sstate
>  0239:# which us unrelocated and tracked by the main sstate manifests.
>  Each
>  recipe
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 395, function: check_output
>  0391: # empty string. That is maintained here for backwards
>  compatibility.
>  0392: kwargs['input'] = '' if kwargs.get('universal_newlines', False)
>  else b''
>  0393:
>  0394: return run(*popenargs, stdout=PIPE, timeout=timeout,
>  check=True,
>  *** 0395: **kwargs).stdout
>  0396:
>  0397:
>  0398:class CompletedProcess(object):
>  0399: """A process that has finished running.
> File:
> '/workdir/sdk/rpi/buildtools/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py',
> lineno: 487, function: run
>  0483: raise
>  0484: retcode = process.poll()
>  0485: if check and retcode:
>  0486: raise CalledProcessError(retcode, process.args,
>  *** 0487: output=stdout, stderr=stderr)
>  0488: return CompletedProcess(process.args, retcode, stdout, stderr)
>  0489:
>  0490:
>  0491:def list2cmdline(seq):
> Exception: subprocess.CalledProcessError: Command
> '/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog'
> returned non-zero exit status 127.
> 
> Subprocess output:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 5:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> 8:
> /workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
> xmlcatalog: not found
> ```
> 
> I believe the problem is that in the
> `postinst-docbook-xsl-stylesheets-native-xmlcatalog`, `xmlcatalog` is not
> an
> absolute path and thus not found.
> This can be traced to the new
> `layers/poky/meta/classes/xmlcatalog.bbclass`. I
> tried to change `xmlcatalog` to `${SYSROOT_DESTDIR}${bindir}/xmlcatalog`
> there,
> but even after cleaning the `docbook-xsl-stylesheets` recipe this change
> had no
> effect. I'm not sure if this class is cached somewhere else or something.
> 
> Can someone help me getting the SDK to work again, and maybe this is
> general
> thing with needs to be fixed?
> 
> 
> Thank you.
> 
> Regards,
> 
> - Michael
> -- 
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listi

[yocto] Using extensible SDK with multilib

2019-08-09 Thread baisch


Hello everyone,

Short version:

I have an 64 bit Yocto Raspberry build with a piece of 32 bit software with
multilib. The goal is now to be able to use the eSDK to build 32 bit
software for that system. After building and installing the eSDK there are
even two files environment-setup-aarch64-poky-linux and
environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi. After sourcing the
32bit armv7ve environment file, devtool is still building my software as 64
bit. Why doesn't it work?

Long version:

The multilib definition in my local config looks like this:

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7ve"
IMAGE_INSTALL_append_raspberrypi3-64 = " lib32-software-dummy"


The software-dummy "hello world" project builds fine in 32 bit.

Now on to the eSDK: The
environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi actually didn't work
out of the box, I needed to add the bottom of
environment-setup-aarch64-poky-linux to
environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi, so devtool is
found.

This part was missing from the armv7ve environment file:

. /workdir/sdk/rpi/buildtools/environment-setup*
export OE_SKIP_SDK_CHECK=1
export DEPLOY_DIR_IMAGE=/workdir/sdk/rpi/tmp/deploy/images/raspberrypi3-64
export PATH=/workdir/sdk/rpi/sysroots/x86_64-pokysdk-linux/usr/bin:$PATH
printf 'SDK environment now set up; additionally you may now run devtool to
perform development tasks.
Run devtool --help for further details.
'
(which bitbake > /dev/null 2>&1 && echo 'WARNING: attempting to use the
extensible SDK in an environment set up to run bitbake - this may lead to
unexpected results. Please source this script in a new shell session
instead.') || true


Another thing I noticed that SDKTARGETSYSROOT in both files point to
/workdir/sdk/rpi/tmp/sysroots/raspberrypi3-64 which is maybe not correct.
Also not very sure about DEPLOY_DIR_IMAGE.


Eg. in environment-setup-aarch64-poky-linux we have:

export CC="aarch64-poky-linux-gcc --sysroot=$SDKTARGETSYSROOT"
export CXX="aarch64-poky-linux-g++ --sysroot=$SDKTARGETSYSROOT"
…
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-


while in environment-setup-armv7ve-vfp-pokymllib32-linux-gnueabi:

export CC="arm-pokymllib32-linux-gnueabi-gcc -march=armv7ve -mfpu=vfp
-mfloat-abi=softfp --sysroot=$SDKTARGETSYSROOT"
export CXX="arm-pokymllib32-linux-gnueabi-g++ -march=armv7ve -mfpu=vfp
-mfloat-abi=softfp --sysroot=$SDKTARGETSYSROOT"
…
export ARCH=arm
export CROSS_COMPILE=arm-pokymllib32-linux-gnueabi-


After sourcing the armv7ve environment file, building the software I added
with devtool, it's still building in 64 bit. Looking at the run.do_install
logfile I see this:

export AR="aarch64-poky-linux-ar"
export AS="aarch64-poky-linux-as "
…
export CC="aarch64-poky-linux-gcc -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/workdir/sdk/rpi/tmp/work/aarch64-poky-linux/cmake-test/1.0-r0/recipe-sysroot"
…
export CCLD="aarch64-poky-linux-gcc -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/workdir/sdk/rpi/tmp/work/aarch64-poky-linux/cmake-test/1.0-r0/recipe-sysroot"


for some reason it's all 64 bit in there and I don't know where this comes
from. The armv7ve environment file also has
/workdir/sdk/rpi/tmp/sysroots/x86_64/usr/bin/arm-pokymllib32-linux-gnueabi
in it's PATH, where the 32 bit compilers seem to live.


The only way I found to build my software is to build a little script that
calls bitbake directly or to add IMAGE_INSTALL_append_raspberrypi3-64 = "
lib32-cmake-test" to the local.config and build the image with devtool. Both
are not nice solutions.

Thank you for any help!

Regards,

- Michael
--


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto update to Sumo with Multilib results in error in do_image_wic

Re: [yocto] Yocto update to Sumo with Multilib results in error in do_image_wic

[yocto] SDK: getting error "xmlcatalog: not found" installing SDK

Re: [yocto] SDK: getting error "xmlcatalog: not found" installing SDK

[yocto] Using extensible SDK with multilib

5 matches

Site Navigation

Mail list logo

Footer information