Date   

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 394 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: libquadmath

staticd
 

I made some progress...

It turns out that libquadmath is failing to build.

When I goto the `build/tmp/work/...../gcc-runtime/9.2.0-r0/gcc-9.2.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi/arm-oe-linux-gnueabi/libquadmath` directory, the only files that are there are:
```
libquadmath  ] ls -l
total 476
-rw-r--r--. 1 2017 oe-builder   4433 Jan  3 16:17 config.h
-rw-r--r--. 1 2017 oe-builder  69297 Jan  3 16:17 config.log
-rwxr-xr-x. 1 2017 oe-builder  77122 Jan  3 16:17 config.status
-rwxr-xr-x. 1 2017 oe-builder 267083 Jan  3 16:17 libtool
-rw-r--r--. 1 2017 oe-builder  57241 Jan  3 16:17 Makefile
-rw-r--r--. 1 2017 oe-builder     23 Jan  3 16:17 stamp-h1
```
In the config.log, there are errors, some of which are expected, but still:
```
libquadmath  ] grep -i error config.log
arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-V'
arm-oe-linux-gnueabi-gcc: fatal error: no input files
arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
arm-oe-linux-gnueabi-gcc: fatal error: no input files
conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory
arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-V'
arm-oe-linux-gnueabi-gcc: fatal error: no input files
arm-oe-linux-gnueabi-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'?
arm-oe-linux-gnueabi-gcc: fatal error: no input files
conftest.c:28:10: fatal error: ac_nonexistent.h: No such file or directory
configure:12551: arm-oe-linux-gnueabi-gcc  -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot -c  -O2 -pipe -g -feliminate-unused-debug-types     -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot=    -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/recipe-sysroot-native=    -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0=/usr/src/debug/gcc-runtime/9.2.0-r0    -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0/include=/usr/src/debug/gcc-runtime/9.2.0-r0/libstdc++-v3/../include    -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work-shared/gcc-9.2.0-r0/gcc-9.2.0/libiberty=/usr/src/debug/gcc-runtime/9.2.0-r0/libstdc++-v3/../libiberty    -fdebug-prefix-map=/home/oe-builder/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/gcc-runtime/9.2.0-r0/gcc-9.2.0/build.arm-oe-linux-gnueabi.arm-oe-linux-gnueabi=/usr/src/debug/gcc-runtime/9.2.0-r0     -Werror  conftest.c >&5
glibcxx_cv_system_error10=yes
glibcxx_cv_system_error11=yes
glibcxx_cv_system_error12=yes
glibcxx_cv_system_error13=yes
glibcxx_cv_system_error14=yes
glibcxx_cv_system_error15=yes
glibcxx_cv_system_error16=yes
glibcxx_cv_system_error17=yes
glibcxx_cv_system_error18=yes
glibcxx_cv_system_error19=yes
glibcxx_cv_system_error1=yes
glibcxx_cv_system_error2=yes
glibcxx_cv_system_error3=yes
glibcxx_cv_system_error4=yes
glibcxx_cv_system_error5=yes
glibcxx_cv_system_error6=yes
glibcxx_cv_system_error7=yes
glibcxx_cv_system_error8=yes
glibcxx_cv_system_error9=yes
```
If I check out another library that I expect to get, like, `libitm`, I see:
```
libquadmath  ] ls -trl ../libitm/
total 2872
-rwxr-xr-x. 1 2017 oe-builder  97435 Jan  3 16:17 config.status
-rw-r--r--. 1 2017 oe-builder  47665 Jan  3 16:17 Makefile
drwxr-xr-x. 2 2017 oe-builder     22 Jan  3 16:17 testsuite
-rw-r--r--. 1 2017 oe-builder    162 Jan  3 16:17 libitm.spec
-rw-r--r--. 1 2017 oe-builder   5251 Jan  3 16:17 config.h
-rw-r--r--. 1 2017 oe-builder     23 Jan  3 16:17 stamp-h1
-rwxr-xr-x. 1 2017 oe-builder 274850 Jan  3 16:17 libtool
-rw-r--r--. 1 2017 oe-builder    868 Jan  3 16:17 gstdint.h
-rw-r--r--. 1 2017 oe-builder 119521 Jan  3 16:17 config.log
-rw-r--r--. 1 2017 oe-builder  50080 Jan  3 16:18 alloc_c.o
...
-rw-r--r--. 1 2017 oe-builder    931 Jan  3 16:18 libitm.la
```

Have you seen something like this before?  I am not sure how to fix this...

Any help is greatly appreciated.

On Sun, Jan 2, 2022 at 5:13 PM staticd via lists.yoctoproject.org <staticd=gmail.com@...> wrote:
So, I built the latest poky and created the example recipe with the `DEPENDS` from my recipe and indeed, I see `libquadmath.so` in `sysroots-components/`.

I am really scratching my head now.  I must be missing something silly somewhere...

My build environment is running `zeus`  and the latest `poky` I grabbed is `honister`  Perhaps something changed that I am just overlooking somehow.

On Sun, Jan 2, 2022 at 2:18 PM staticd via lists.yoctoproject.org <staticd=gmail.com@...> wrote:
Thank you, Konrad.

I have tried both of the approaches (local.conf and gcc-runtime_%.bbappend/gcc_%.bbappend), still `libquadmath.so` is not being built.

I will keep fiddling but I think we are onto something.

The interesting thing I found is that `libquadmath.so` IS being built for the nativesdk but NOT when I add `DEPENDS = "virtual/${TARGET_PREFIX}compillerlibs"` to my recipe.

Perhaps, because `FORTRAN = ""` is in the gcc_%.bb, maybe that should be something less strict?

I might be screwing up my bbappend too...

My append is in `meta-mylayer/recipes-devtools/gcc/gcc-runtime_%.bbappend`

Which is mapped correctly to $BBFILES n my layers `layer.conf`

On Sun, Jan 2, 2022 at 2:07 PM Konrad Weihmann <kweihmann@...> wrote:
The following I just found in local.conf.sample.extended

# Enabling FORTRAN
# Note this is not officially supported and is just illustrated here to
# show an example of how it can be done
# You'll also need your fortran recipe to depend on libgfortran
FORTRAN:forcevariable = ",fortran"

guess that will solve your issue without the need for a bbappend.
Just inject that line via distro or local.conf

On 02.01.22 18:31, staticd wrote:
> I think to clarify...what I need are these files:
>
> --- snipped from gcc-runtime.inc ---
> ```
> FILES_libquadmath = "${libdir}/libquadmath*.so.*"
> SUMMARY_libquadmath = "GNU quad-precision math library"
> FILES_libquadmath-dev = "\
>      ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
>      ${libdir}/libquadmath*.so \
>      ${libdir}/libquadmath.la <http://libquadmath.la> \
> "
> ```
> ---
> to be in my $STAGING_LIBDIR
>
> So far, I have been unable to figure out how to do that, unfortunately.
>
> On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@...
> <mailto:staticd@...>> wrote:
>
>     Thank you, Michael.
>
>     I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`
>
>     and `do_compile[depends] +=
>     "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`
>
>     However, libquadmath.so is still not present in `recipe-sysroot/lib`
>
>     I used the `do_check` task from gcc_runtime but that still isn't
>     providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I
>     need it.
>
>     Many thanks.
>
>     On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...
>     <mailto:michael.ho@...>> wrote:
>
>         Not familiar with Fortran but maybe it helps to know that this
>         is normally handled with the DEPENDS mechanism. When you add
>         other recipes as dependencies to your recipe, the task
>         do_prepare_recipe_sysroot (run before do_compile) will make hard
>         links to the files from those dependency recipes into that
>         recipe-sysroot directory.
>
>         See:
>         https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot
>         <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>
>
>         Kind regards,
>         Michael
>
>         On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...
>         <mailto:staticd@...>> wrote:
>
>             okay...I think I have a more interesting question now...
>
>             In the package I am building I have some Fortran code that
>             requires `libquadmath`
>
>             I see that `gcc-runtime` provides the library but I need the
>             library present in `recipe-sysroot/lib` when my `do_compile`
>             runs
>
>             Is there a way for me to do that?
>
>             My current approach is to build my image, copy the
>             libraries/includes to my recipe and `install` them in
>             `recipe-sysroot` before `do_compile`
>
>             This doesn't seem like the correct approach but I am not
>             sure how else to do it at this point
>
>             Any help would be greatly appreciated.
>
>
>
>
>
>
>







Re: libquadmath

staticd
 

So, I built the latest poky and created the example recipe with the `DEPENDS` from my recipe and indeed, I see `libquadmath.so` in `sysroots-components/`.

I am really scratching my head now.  I must be missing something silly somewhere...

My build environment is running `zeus`  and the latest `poky` I grabbed is `honister`  Perhaps something changed that I am just overlooking somehow.

On Sun, Jan 2, 2022 at 2:18 PM staticd via lists.yoctoproject.org <staticd=gmail.com@...> wrote:
Thank you, Konrad.

I have tried both of the approaches (local.conf and gcc-runtime_%.bbappend/gcc_%.bbappend), still `libquadmath.so` is not being built.

I will keep fiddling but I think we are onto something.

The interesting thing I found is that `libquadmath.so` IS being built for the nativesdk but NOT when I add `DEPENDS = "virtual/${TARGET_PREFIX}compillerlibs"` to my recipe.

Perhaps, because `FORTRAN = ""` is in the gcc_%.bb, maybe that should be something less strict?

I might be screwing up my bbappend too...

My append is in `meta-mylayer/recipes-devtools/gcc/gcc-runtime_%.bbappend`

Which is mapped correctly to $BBFILES n my layers `layer.conf`

On Sun, Jan 2, 2022 at 2:07 PM Konrad Weihmann <kweihmann@...> wrote:
The following I just found in local.conf.sample.extended

# Enabling FORTRAN
# Note this is not officially supported and is just illustrated here to
# show an example of how it can be done
# You'll also need your fortran recipe to depend on libgfortran
FORTRAN:forcevariable = ",fortran"

guess that will solve your issue without the need for a bbappend.
Just inject that line via distro or local.conf

On 02.01.22 18:31, staticd wrote:
> I think to clarify...what I need are these files:
>
> --- snipped from gcc-runtime.inc ---
> ```
> FILES_libquadmath = "${libdir}/libquadmath*.so.*"
> SUMMARY_libquadmath = "GNU quad-precision math library"
> FILES_libquadmath-dev = "\
>      ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
>      ${libdir}/libquadmath*.so \
>      ${libdir}/libquadmath.la <http://libquadmath.la> \
> "
> ```
> ---
> to be in my $STAGING_LIBDIR
>
> So far, I have been unable to figure out how to do that, unfortunately.
>
> On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@...
> <mailto:staticd@...>> wrote:
>
>     Thank you, Michael.
>
>     I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`
>
>     and `do_compile[depends] +=
>     "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`
>
>     However, libquadmath.so is still not present in `recipe-sysroot/lib`
>
>     I used the `do_check` task from gcc_runtime but that still isn't
>     providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I
>     need it.
>
>     Many thanks.
>
>     On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...
>     <mailto:michael.ho@...>> wrote:
>
>         Not familiar with Fortran but maybe it helps to know that this
>         is normally handled with the DEPENDS mechanism. When you add
>         other recipes as dependencies to your recipe, the task
>         do_prepare_recipe_sysroot (run before do_compile) will make hard
>         links to the files from those dependency recipes into that
>         recipe-sysroot directory.
>
>         See:
>         https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot
>         <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>
>
>         Kind regards,
>         Michael
>
>         On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...
>         <mailto:staticd@...>> wrote:
>
>             okay...I think I have a more interesting question now...
>
>             In the package I am building I have some Fortran code that
>             requires `libquadmath`
>
>             I see that `gcc-runtime` provides the library but I need the
>             library present in `recipe-sysroot/lib` when my `do_compile`
>             runs
>
>             Is there a way for me to do that?
>
>             My current approach is to build my image, copy the
>             libraries/includes to my recipe and `install` them in
>             `recipe-sysroot` before `do_compile`
>
>             This doesn't seem like the correct approach but I am not
>             sure how else to do it at this point
>
>             Any help would be greatly appreciated.
>
>
>
>
>
>
>




Re: libquadmath

staticd
 

Thank you, Konrad.

I have tried both of the approaches (local.conf and gcc-runtime_%.bbappend/gcc_%.bbappend), still `libquadmath.so` is not being built.

I will keep fiddling but I think we are onto something.

The interesting thing I found is that `libquadmath.so` IS being built for the nativesdk but NOT when I add `DEPENDS = "virtual/${TARGET_PREFIX}compillerlibs"` to my recipe.

Perhaps, because `FORTRAN = ""` is in the gcc_%.bb, maybe that should be something less strict?

I might be screwing up my bbappend too...

My append is in `meta-mylayer/recipes-devtools/gcc/gcc-runtime_%.bbappend`

Which is mapped correctly to $BBFILES n my layers `layer.conf`

On Sun, Jan 2, 2022 at 2:07 PM Konrad Weihmann <kweihmann@...> wrote:
The following I just found in local.conf.sample.extended

# Enabling FORTRAN
# Note this is not officially supported and is just illustrated here to
# show an example of how it can be done
# You'll also need your fortran recipe to depend on libgfortran
FORTRAN:forcevariable = ",fortran"

guess that will solve your issue without the need for a bbappend.
Just inject that line via distro or local.conf

On 02.01.22 18:31, staticd wrote:
> I think to clarify...what I need are these files:
>
> --- snipped from gcc-runtime.inc ---
> ```
> FILES_libquadmath = "${libdir}/libquadmath*.so.*"
> SUMMARY_libquadmath = "GNU quad-precision math library"
> FILES_libquadmath-dev = "\
>      ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
>      ${libdir}/libquadmath*.so \
>      ${libdir}/libquadmath.la <http://libquadmath.la> \
> "
> ```
> ---
> to be in my $STAGING_LIBDIR
>
> So far, I have been unable to figure out how to do that, unfortunately.
>
> On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@...
> <mailto:staticd@...>> wrote:
>
>     Thank you, Michael.
>
>     I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`
>
>     and `do_compile[depends] +=
>     "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`
>
>     However, libquadmath.so is still not present in `recipe-sysroot/lib`
>
>     I used the `do_check` task from gcc_runtime but that still isn't
>     providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I
>     need it.
>
>     Many thanks.
>
>     On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...
>     <mailto:michael.ho@...>> wrote:
>
>         Not familiar with Fortran but maybe it helps to know that this
>         is normally handled with the DEPENDS mechanism. When you add
>         other recipes as dependencies to your recipe, the task
>         do_prepare_recipe_sysroot (run before do_compile) will make hard
>         links to the files from those dependency recipes into that
>         recipe-sysroot directory.
>
>         See:
>         https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot
>         <https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>
>
>         Kind regards,
>         Michael
>
>         On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...
>         <mailto:staticd@...>> wrote:
>
>             okay...I think I have a more interesting question now...
>
>             In the package I am building I have some Fortran code that
>             requires `libquadmath`
>
>             I see that `gcc-runtime` provides the library but I need the
>             library present in `recipe-sysroot/lib` when my `do_compile`
>             runs
>
>             Is there a way for me to do that?
>
>             My current approach is to build my image, copy the
>             libraries/includes to my recipe and `install` them in
>             `recipe-sysroot` before `do_compile`
>
>             This doesn't seem like the correct approach but I am not
>             sure how else to do it at this point
>
>             Any help would be greatly appreciated.
>
>
>
>
>
>
>


Re: libquadmath

Konrad Weihmann <kweihmann@...>
 

The following I just found in local.conf.sample.extended

# Enabling FORTRAN
# Note this is not officially supported and is just illustrated here to
# show an example of how it can be done
# You'll also need your fortran recipe to depend on libgfortran
FORTRAN:forcevariable = ",fortran"

guess that will solve your issue without the need for a bbappend.
Just inject that line via distro or local.conf

On 02.01.22 18:31, staticd wrote:
I think to clarify...what I need are these files:
--- snipped from gcc-runtime.inc ---
```
FILES_libquadmath = "${libdir}/libquadmath*.so.*"
SUMMARY_libquadmath = "GNU quad-precision math library"
FILES_libquadmath-dev = "\
    ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
    ${libdir}/libquadmath*.so \
    ${libdir}/libquadmath.la <http://libquadmath.la> \
"
```
---
to be in my $STAGING_LIBDIR
So far, I have been unable to figure out how to do that, unfortunately.
On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@... <mailto:staticd@...>> wrote:
Thank you, Michael.
I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`
and `do_compile[depends] +=
"virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`
However, libquadmath.so is still not present in `recipe-sysroot/lib`
I used the `do_check` task from gcc_runtime but that still isn't
providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I
need it.
Many thanks.
On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...
<mailto:michael.ho@...>> wrote:
Not familiar with Fortran but maybe it helps to know that this
is normally handled with the DEPENDS mechanism. When you add
other recipes as dependencies to your recipe, the task
do_prepare_recipe_sysroot (run before do_compile) will make hard
links to the files from those dependency recipes into that
recipe-sysroot directory.
See:
https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot
<https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>
Kind regards,
Michael
On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...
<mailto:staticd@...>> wrote:
okay...I think I have a more interesting question now...
In the package I am building I have some Fortran code that
requires `libquadmath`
I see that `gcc-runtime` provides the library but I need the
library present in `recipe-sysroot/lib` when my `do_compile`
runs
Is there a way for me to do that?
My current approach is to build my image, copy the
libraries/includes to my recipe and `install` them in
`recipe-sysroot` before `do_compile`
This doesn't seem like the correct approach but I am not
sure how else to do it at this point
Any help would be greatly appreciated.


Re: libquadmath

Konrad Weihmann <kweihmann@...>
 

I think the reason of that is that fortran support isn't enabled in default gcc-runtime recipe.

from gcc-runtime.inc:

RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \
"

activates the configuration of libquadmath if either ',fortran' or ',f77' is set in 'FORTRAN' variable.
Unfortunately this variable seems to be set to "" since gcc version 9 update

By just adding

FORTRAN = ",fortran"

to a gcc-runtime_%.bbappend I could create the needed files in the sysroot-components directory

gcc-runtime/usr/lib/libstdc++.so
gcc-runtime/usr/lib/libitm.spec
->> gcc-runtime/usr/lib/libquadmath.so.0.0.0
gcc-runtime/usr/lib/libstdc++.so.6
gcc-runtime/usr/lib/libitm.so.1.0.0
gcc-runtime/usr/lib/libatomic.so.1
gcc-runtime/usr/lib/libgomp.spec
gcc-runtime/usr/lib/libitm.a

now as you already have set `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"` it should automatically make the lib available to your recipe workspace.

On 02.01.22 18:31, staticd wrote:
I think to clarify...what I need are these files:
--- snipped from gcc-runtime.inc ---
```
FILES_libquadmath = "${libdir}/libquadmath*.so.*"
SUMMARY_libquadmath = "GNU quad-precision math library"
FILES_libquadmath-dev = "\
    ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
    ${libdir}/libquadmath*.so \
    ${libdir}/libquadmath.la <http://libquadmath.la> \
"
```
---
to be in my $STAGING_LIBDIR
So far, I have been unable to figure out how to do that, unfortunately.
On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@... <mailto:staticd@...>> wrote:
Thank you, Michael.
I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`
and `do_compile[depends] +=
"virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`
However, libquadmath.so is still not present in `recipe-sysroot/lib`
I used the `do_check` task from gcc_runtime but that still isn't
providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I
need it.
Many thanks.
On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...
<mailto:michael.ho@...>> wrote:
Not familiar with Fortran but maybe it helps to know that this
is normally handled with the DEPENDS mechanism. When you add
other recipes as dependencies to your recipe, the task
do_prepare_recipe_sysroot (run before do_compile) will make hard
links to the files from those dependency recipes into that
recipe-sysroot directory.
See:
https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot
<https://docs.yoctoproject.org/singleindex.html#do-prepare-recipe-sysroot>
Kind regards,
Michael
On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...
<mailto:staticd@...>> wrote:
okay...I think I have a more interesting question now...
In the package I am building I have some Fortran code that
requires `libquadmath`
I see that `gcc-runtime` provides the library but I need the
library present in `recipe-sysroot/lib` when my `do_compile`
runs
Is there a way for me to do that?
My current approach is to build my image, copy the
libraries/includes to my recipe and `install` them in
`recipe-sysroot` before `do_compile`
This doesn't seem like the correct approach but I am not
sure how else to do it at this point
Any help would be greatly appreciated.


Re: libquadmath

staticd
 

I think to clarify...what I need are these files:

--- snipped from gcc-runtime.inc ---
```
FILES_libquadmath = "${libdir}/libquadmath*.so.*"
SUMMARY_libquadmath = "GNU quad-precision math library"
FILES_libquadmath-dev = "\
    ${libdir}/${TARGET_SYS}/${BINV}/include/quadmath* \
    ${libdir}/libquadmath*.so \
    ${libdir}/libquadmath.la \
"
```
---
to be in my $STAGING_LIBDIR

So far, I have been unable to figure out how to do that, unfortunately.

On Sun, Jan 2, 2022 at 12:23 PM staticd <staticd@...> wrote:
Thank you, Michael.

I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`

and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`

However, libquadmath.so is still not present in `recipe-sysroot/lib`

I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it.

Many thanks.

On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...> wrote:
Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. 


Kind regards,
Michael

On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote:
okay...I think I have a more interesting question now...

In the package I am building I have some Fortran code that requires `libquadmath`

I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs

Is there a way for me to do that?

My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile`

This doesn't seem like the correct approach but I am not sure how else to do it at this point

Any help would be greatly appreciated.




Re: libquadmath

staticd
 

Thank you, Michael.

I have `DEPENDS = "virtual/arm-oe-linux-gnueabi-compilerlibs"`

and `do_compile[depends] += "virtual/arm-oe-linux-gnueabi-compilerlibs:do_check"`

However, libquadmath.so is still not present in `recipe-sysroot/lib`

I used the `do_check` task from gcc_runtime but that still isn't providing `libquadmath.so` in my $STAGING_LIBDIR, which is where I need it.

Many thanks.

On Sun, Jan 2, 2022 at 12:17 PM Michael Ho <michael.ho@...> wrote:
Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. 


Kind regards,
Michael

On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote:
okay...I think I have a more interesting question now...

In the package I am building I have some Fortran code that requires `libquadmath`

I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs

Is there a way for me to do that?

My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile`

This doesn't seem like the correct approach but I am not sure how else to do it at this point

Any help would be greatly appreciated.




Re: libquadmath

Michael Ho
 

Not familiar with Fortran but maybe it helps to know that this is normally handled with the DEPENDS mechanism. When you add other recipes as dependencies to your recipe, the task do_prepare_recipe_sysroot (run before do_compile) will make hard links to the files from those dependency recipes into that recipe-sysroot directory. 


Kind regards,
Michael


On Sun, 2 Jan 2022, 6:06 pm staticd, <staticd@...> wrote:
okay...I think I have a more interesting question now...

In the package I am building I have some Fortran code that requires `libquadmath`

I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs

Is there a way for me to do that?

My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile`

This doesn't seem like the correct approach but I am not sure how else to do it at this point

Any help would be greatly appreciated.




libquadmath

staticd
 

okay...I think I have a more interesting question now...

In the package I am building I have some Fortran code that requires `libquadmath`

I see that `gcc-runtime` provides the library but I need the library present in `recipe-sysroot/lib` when my `do_compile` runs

Is there a way for me to do that?

My current approach is to build my image, copy the libraries/includes to my recipe and `install` them in `recipe-sysroot` before `do_compile`

This doesn't seem like the correct approach but I am not sure how else to do it at this point

Any help would be greatly appreciated.


[auto-upgrade-helper][PATCH] devtool: return both stdout and stderr

Alexander Kanavin
 

At some point devtool started printing to stderr, which means
patch rebase issues weren't anymore correctly caught, and bogus
updates were being sent out.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
modules/utils/devtool.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/utils/devtool.py b/modules/utils/devtool.py
index 0d27bb0..c26061f 100644
--- a/modules/utils/devtool.py
+++ b/modules/utils/devtool.py
@@ -19,7 +19,7 @@ class Devtool(object):
raise DevtoolError("The following devtool command failed: " + operation,
e.stdout, e.stderr)

- return stdout
+ return stdout + stderr

def upgrade(self, recipe, version = None, revision = None):
cmd = " upgrade " + recipe
--
2.33.1


How to add WIFI debug tool to custom image #raspberrypi #ubuntu #yocto #devtool #distro

mihirdave36@...
 

Hello,

How can I add any generic WiFi debug tool to Yocto imgae?

Thanks
Mihir


How to add Alsa loopback / Alsa lib support to custom image #linux #raspberrypi #ubuntu #yocto #devtool

mihirdave36@...
 

Hello,
Happy New Year

I am trying to learn Yocto, & implement it on NXP & RPI 4 dev boards.
so, could you please guide me how can i add,
1- Alsa loopback or Alsa library.
to my custom Yocto image.

Thanks
Mihir


[meta-security][PATCH] google-authenticator-libpam: update to 1.09

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
...cator-libpam_1.08.bb => google-authenticator-libpam_1.09.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/google-authenticator-libpam/{google-authenticator-libpam_1.08.bb => google-authenticator-libpam_1.09.bb} (92%)

diff --git a/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb b/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb
similarity index 92%
rename from recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb
rename to recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb
index e8ddf29..8a0b1ee 100644
--- a/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.08.bb
+++ b/recipes-security/google-authenticator-libpam/google-authenticator-libpam_1.09.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
LICENSE = "Apache-2.0"

SRC_URI = "git://github.com/google/google-authenticator-libpam.git;branch=master;protocol=https"
-SRCREV = "2c7415d950fb0b4a7f779f045910666447b100ef"
+SRCREV = "962f353aac6cfc7b804547319db40f8b804f0b6c"

DEPENDS = "libpam"

--
2.25.1


[meta-cgl][PATCH 3/3] cluster-glue: add UPSTREAM_CHECK_GITTAGREGEX

Yi Zhao
 

Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version.

Before the patch:
$ devtool latest-version cluster-glue
INFO: Current version: 1.0.12
INFO: Latest version: 10
INFO: Latest version's commit: 62fac3c02affab05abe39c185dad3a91367d3f58

After the patch:
$ devtool latest-version cluster-glue
INFO: Current version: 1.0.12
INFO: Latest version: 1.0.12
INFO: Latest version's commit: 1bc77825c0cfb0c80f9c82a061af7ede68676cb4

Signed-off-by: Yi Zhao <yi.zhao@...>
---
meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
index acd3149..c9d1bac 100644
--- a/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-glue/cluster-glue_1.0.12.bb
@@ -22,6 +22,8 @@ SRC_URI:append_libc-uclibc = " file://kill-stack-protector.patch"

SRCREV = "fd5a3befacd23d056a72cacd2b8ad6bba498e56b"

+UPSTREAM_CHECK_GITTAGREGEX = "glue-(?P<pver>\d+(\.\d+)+)"
+
inherit autotools useradd pkgconfig systemd multilib_script multilib_header

SYSTEMD_SERVICE:${PN} = "logd.service"
--
2.25.1


[meta-cgl][PATCH 2/3] ocfs2-tools: add UPSTREAM_CHECK_GITTAGREGEX

Yi Zhao
 

Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version.

Before the patch:
$ devtool latest-version ocfs2-tools
INFO: Current version: 1.8.6
INFO: Latest version: 2
INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6

After the patch:
$ devtool latest-version ocfs2-tools
INFO: Current version: 1.8.6
INFO: Latest version: 1.8.7
INFO: Latest version's commit: 80a60d697d9052d3f196a932df3d1fb5f0df52d6

Signed-off-by: Yi Zhao <yi.zhao@...>
---
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
index 7c32c54..28ef4b0 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.8.6.bb
@@ -22,6 +22,9 @@ SRC_URI = "git://github.com/markfasheh/ocfs2-tools;branch=master;protocol=https
file://0001-o2cb.init.sh-Remove-unneeded-lib-lsb-init-functions.patch \
"
SRCREV = "4d76ceb4aa7aaa1fd595368089e99575d708f719"
+
+UPSTREAM_CHECK_GITTAGREGEX = "ocfs2-tools-(?P<pver>\d+(\.\d+)+)"
+
S = "${WORKDIR}/git"

inherit autotools-brokensep pkgconfig systemd
--
2.25.1


[meta-cgl][PATCH 1/3] resource-agents: add UPSTREAM_CHECK_GITTAGREGEX

Yi Zhao
 

Add UPSTREAM_CHECK_GITTAGREGEX to check the correct latest version.

Before the patch:
$ devtool latest-version resource-agents
INFO: Current version: 4.5.0
INFO: Latest version: 10
INFO: Latest version's commit: 5cf93783eafa22e8b82d50834bfb76b9e8434783

After the patch:
$ devtool latest-version resource-agents
INFO: Current version: 4.5.0
INFO: Latest version: 4.10.0
INFO: Latest version's commit: fd0720f73a06042ad0a5475a3398096b2912cf5f

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../cluster-resource-agents/resource-agents_4.5.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
index 00ddd22..c8b2fbd 100644
--- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.5.0.bb
@@ -24,6 +24,8 @@ SRC_URI = "git://github.com/ClusterLabs/resource-agents;branch=main;protocol=htt

SRCREV = "fee181320547365d7f8c88cca2b32801412b933d"

+UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)"
+
S="${WORKDIR}/git"

LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe \
--
2.25.1


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Wed, Dec 29, 2021 at 6:15 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote:



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.
You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2
Sorry Khem, I'm not quite following you. I tried the following patch
(https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you
meant however my build configuration still shows the tune set to
mips32r2 https://pastebin.com/izP9thVW

What am I missing?
Nevermind, I scraped the last patch, recreated my BUILD_DIR, set
MACHINE = "qemumips" and added DEFAULTTUNE = "mips" in my local.conf.
Now the build configuration correct https://pastebin.com/pkkRVL58 and
I'm now waiting for the toolchain to finish so I can attempt to build
realtek's u-boot.





Regards,
Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

davis roman <davis.roman84@...>
 

On Wed, Dec 29, 2021 at 5:30 PM Khem Raj <raj.khem@...> wrote:



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:

On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:

Hi,

On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:

I generated an internal mips toolchain built against musl and I tried
to compile u-boot but unfortunately, I'm getting "opcode not
supported" error messages. https://pastebin.com/QdcLxy69
If instead I use the realtek provided prebuilt toolchain then u-boot
compiles successfully. https://pastebin.com/zcQ5kc20

I'm thinking that Realtek's toolchain has patches specific to their
SoC that have not been pushed upstream. Could this be the reason I'm
unable to compile uboot?
I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.
You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2
Sorry Khem, I'm not quite following you. I tried the following patch
(https://pastebin.com/rkmQ3t6P) thinking perhaps this is what you
meant however my build configuration still shows the tune set to
mips32r2 https://pastebin.com/izP9thVW

What am I missing?





Regards,
Anders Montonen


Re: building image for Realtek RTS3916N mips SoC using vendor provided prebuilt external uClibc toolchain

Khem Raj
 



On Wed, Dec 29, 2021 at 2:20 PM Davis Roman <davis.roman84@...> wrote:
On Wed, Dec 29, 2021 at 2:21 PM Anders Montonen <Anders.Montonen@...> wrote:
>
> Hi,
>
> > On 29 Dec 2021, at 9:53, davis roman <davis.roman84@...> wrote:
> >
> > I generated an internal mips toolchain built against musl and I tried
> > to compile u-boot but unfortunately, I'm getting "opcode not
> > supported" error messages. https://pastebin.com/QdcLxy69
> > If instead I use the realtek provided prebuilt toolchain then u-boot
> > compiles successfully. https://pastebin.com/zcQ5kc20
> >
> > I'm thinking that Realtek's toolchain has patches specific to their
> > SoC that have not been pushed upstream. Could this be the reason I'm
> > unable to compile uboot?
>
> I’m guessing that your U-Boot config doesn’t set the correct MIPS architecture revision. The compiler error shows that you’re trying to assemble a MIPS32r1 instruction, but the compiler is targeting the original MIPS1 architecture. The Realtek toolchain may have set the default architecture to match the SoC, but the fix is to update the config to match the hardware.

You're right. I didn't realize the RX5281 core on the RTS3916N only
supports mips1 or mips16 (https://pasteboard.co/IpsqN6GkBYAs.png).

I happened to have a mips sourcery toolchain installed on my machine
(https://sourcery.sw.siemens.com/GNUToolchain/package12797/public/mips-linux-gnu/mips-2014.05-27-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
so I pointed that to u-boot without modifying anything else and it was
able to compile u-boot successfully. Woot!
https://pastebin.com/ySPFae5u

I suppose the next step would be to generate a mips1 yocto toolchain
however according to the available tune values it appears only mips32
or mips64 is available

Any suggestions on how to generate a mips1 yocto toolchain or if
that's even supported?

Yes it’s supported although it’s not default for qemumips so the simple trick you can do is change the DEFAULTTUNE setting in the qemumips.conf away from mips32r2


>
> Regards,
> Anders Montonen

1721 - 1740 of 57385