[Fwd: gobject introspection release notes]

[Fwd: gobject introspection release notes]

[alexander.kanavin]

Hello,

here is the information about gobject introspection that should be placed
to the release notes of the upcoming yocto release.

1. Introduction

This Yocto release adds support for generating and packaging GObject
introspection data. GObject introspection data is a description of the API
provided by libraries built on top of GLib framework, and that framework's
GObject mechanism in particular. The data is generated when building such
a library, by linking the library with a small executable binary that
asks the library to describe itself, then executing the binary and
processing its output. Making this work in a cross-compilation environment
is difficult, because the library is produced for the target architecture,

but its code needs to be executed on the build host. This problem is
solved in Yocto by running the code through Qemu emulator which allows
precisely that, but unfortunately Qemu does not always work perfectly (see
known issues list below).

2. Why all this trouble?

GObject introspection is nowadays the standard mechanism for accessing
GObject-based software from runtime environments. If you want to construct

GStreamer pipelines using Python, or control UPnP infrastructure using
Javascript and GUPnP, this is the only way to do it.

3. Where does generated introspection data go?

Gir files go to -dev packages, typelib files go to main packages
(they are packaged together with libraries that are introspected).

4. I don't need introspection data (or Qemu does not work on my
combination of build host and target architecture), how can I switch it
off?

You have two options:
a) add
DISTRO_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data" to your
distro configuration. This will disable building introspection data using
qemu, but will still enable building introspection tools and  libraries
(building them does not require the use of qemu).

b) add
MACHINE_FEATURES_BACKFILL_CONSIDERED = "qemu-usermode"
to your machine configuration. This will disable the use of qemu when
building packages for your machine; at the moment this feature is
used only by introspection recipes and has the same effect as option a),
but in the future there may be other features that this affects.

If introspection data is disabled, it can still be obtained through other
means (for example, by copying the data from a suitable sysroot, or
generating it on the target hardware). Yocto currently does not provide
specific support for these techniques.

5. How do I enable generating introspection data in my library package?
(variant: I have a library that no longer builds against latest Yocto
release, and build process prints introspection related errors, how to fix
it?)

a. Inherit gobject-introspection class.

b. Make sure introspection is not disabled anywhere in the recipe or its
includes. Also, make sure that 'gobject-introspection-data' is neither

in DISTRO_FEATURES_BACKFILL_CONSIDERED, and 'qemu-usermode is not in
MACHINE_FEATURES_BACKFILL_CONSIDERED, or nothing will happen.

c. Try to build the recipe; if this results in build errors that look like
something is unable to find .so libraries, check where these
libraries
are in the source tree and add GIR_EXTRA_LIBS_PATH=${B}/something/.libs to
the recipe (look at recipes in oe-core which have that variable for a
template).

c. Any other errors probably mean that introspection support in a package
is not entirely standard, and breaks down in a cross-compilation
environment. Custom-made fixing is needed then - please come to the yocto
mailing list for help.

6. How do I test that introspection works in an image?

a. Make sure that 'gobject-introspection-data' is not in
DISTRO_FEATURES_BACKFILL_CONSIDERED and 'qemu-usermode' is not in
MACHINE_FEATURES_BACKFILL_CONSIDERED.

b. Build core-image-sato.

c. Start terminal, start python in the terminal.

d. Type out something like:

>>> from gi.repository import GLib
>>> GLib.get_host_name()

e. Also, try something more advanced, for example:
http://python-gtk-3-tutorial.readthedocs.org/en/latest/introduction.html

7. Known issues:

- qemu-ppc64 crashes out immediately; so introspection data
cannot be built on that architecture

- x32 is not supported by qemu; therefore introspection data is disabled
there.

- musl is causing transient glib binaries to crash on assertion failures,
so generating introspection data is disabled there as well

- introspection is disabled for some specific packages under specific
arhcitectures (such as gcr, libsecret, webkit), because qemu is not able
to run the binaries correctly


Thanks,
Alex

Re: [Fwd: gobject introspection release notes]

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]

Any ideas as to why "qemu-ppc64 crashes out immediately"?
I can confirm the build ends in a segfault when I tried building gobject-introspection for the t1042d4rdb-64b machine.  
I did get one qemu crash recorded by Fedora but the actual crash dumps (appended) are for a PowerPC.  That said, given the dump, either the processor got nowhere or they are likely corrupt.  The invalid access reported is roughly to the stack but with the upper 32-bits zeroed.
If I configure bitbake for a 32-bit build (t1042d4rdb) then the build fails with  "Unable to find CPU definition" (cpu e5500) so a 32-bit build is out of the question too.
The command line from the wrapper is:PSEUDO_UNLOAD=1 qemu-ppc -r 2.6.32  -cpu e5500 -L /home/chris/yocto/build/tmp/sysroots/t1042d4rdb -E LD_LIBRARY_PATH=$GIR_EXTRA_LIBS_PATH:.libs:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//usr/lib:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//lib  "$@"
The cpu is supported by the fedora qemu-ppc64, but not qemu-ppc - ie it's a 64-bit processor that's not supported in 32-bit mode.
This is not massively urgent for me but it may be important in the future and I am curious as to whether the problem is in the qemu emulation or in the emulated code.
Regards,Chris 

| Invalid data memory access: 0x00000000007fe8f0| NIP 00000040008046c8   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0| MSR 8000000000006000 HID0 0000000000000000  HF 0000000000006000 idx 0| TB 00025634 110100571322161| GPR00 0000000000000000 00000040007fe970 0000004000848e00 00000040007fe970| GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000| CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff| FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPSCR 0000000000000000| Invalid segfault errno (42000000)| NIP 00000040008046c8   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0| MSR 8000000000006000 HID0 0000000000000000  HF 0000000000006000 idx 0| TB 00025634 110100578368626| GPR00 0000000000000000 00000040007fe970 0000004000848e00 00000040007fe970| GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000| GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000| CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff| FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000| FPSCR 0000000000000000| qemu: uncaught target signal 11 (Segmentation fault) - core dumped
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 5773 bytes --]

Re: [Fwd: gobject introspection release notes]

[Zhenhua Luo]

[-- Attachment #1: Type: text/plain, Size: 5226 bytes --]

Hello Chris,

Please see my inline comments.


Best Regards,

Zhenhua

From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Chris Trobridge
Sent: Monday, April 25, 2016 11:01 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] [Fwd: gobject introspection release notes]

Any ideas as to why "qemu-ppc64 crashes out immediately"?

I can confirm the build ends in a segfault when I tried building gobject-introspection for the t1042d4rdb-64b machine.
[Luo Zhenhua-B19537] This is a gobject-introspection support issue of QEMU PPC64, the fix is not available now, you can use the following workaround to bypass the issue.
http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18

I did get one qemu crash recorded by Fedora but the actual crash dumps (appended) are for a PowerPC.  That said, given the dump, either the processor got nowhere or they are likely corrupt.  The invalid access reported is roughly to the stack but with the upper 32-bits zeroed.

If I configure bitbake for a 32-bit build (t1042d4rdb) then the build fails with  "Unable to find CPU definition" (cpu e5500) so a 32-bit build is out of the question too.

The command line from the wrapper is:
PSEUDO_UNLOAD=1 qemu-ppc -r 2.6.32  -cpu e5500 -L /home/chris/yocto/build/tmp/sysroots/t1042d4rdb -E LD_LIBRARY_PATH=$GIR_EXTRA_LIBS_PATH:.libs:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//usr/lib:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//lib  "$@"
[Luo Zhenhua-B19537] Please fetch the latest commit, the issue is fixed by http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=krogoth&id=27e202f2d9114a64b67c83eb7eafeb12de5ceea7.

The cpu is supported by the fedora qemu-ppc64, but not qemu-ppc - ie it's a 64-bit processor that's not supported in 32-bit mode.

This is not massively urgent for me but it may be important in the future and I am curious as to whether the problem is in the qemu emulation or in the emulated code.

Regards,
Chris
| Invalid data memory access: 0x00000000007fe8f0
| NIP 00000040008046c8   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
| MSR 8000000000006000 HID0 0000000000000000  HF 0000000000006000 idx 0
| TB 00025634 110100571322161
| GPR00 0000000000000000 00000040007fe970 0000004000848e00 00000040007fe970
| GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff
| FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPSCR 0000000000000000
| Invalid segfault errno (42000000)
| NIP 00000040008046c8   LR 0000000000000000 CTR 0000000000000000 XER 0000000000000000 CPU#0
| MSR 8000000000006000 HID0 0000000000000000  HF 0000000000006000 idx 0
| TB 00025634 110100578368626
| GPR00 0000000000000000 00000040007fe970 0000004000848e00 00000040007fe970
| GPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| GPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| CR 00000000  [ -  -  -  -  -  -  -  -  ]             RES ffffffffffffffff
| FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
| FPSCR 0000000000000000
| qemu: uncaught target signal 11 (Segmentation fault) - core dumped


[-- Attachment #2: Type: text/html, Size: 17106 bytes --]

Re: [Fwd: gobject introspection release notes]

[Alexander Kanavin]

On 04/26/2016 11:05 AM, Zhenhua Luo wrote:
> Any ideas as to why "qemu-ppc64 crashes out immediately"?
>
> I can confirm the build ends in a segfault when I tried building
> gobject-introspection for the t1042d4rdb-64b machine.
>
> */[Luo Zhenhua-B19537] This is a gobject-introspection support issue of
> QEMU PPC64, the fix is not available now, you can use the following
> workaround to bypass the issue. /*
>
> */http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18/*

I'm afraid disabling introspection data is not an acceptable solution 
for Chris, because he does want to have that data.

Also, I'll send a fix to disable building of introspection data on all 
ppc64 machines for now.

Alex

Re: [Fwd: gobject introspection release notes]

[Chris Trobridge]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

> Subject: Re: [yocto] [Fwd: gobject introspection release notes]
> To: zhenhua.luo@nxp.com; christrobridge@hotmail.com
> CC: yocto@yoctoproject.org
> From: alexander.kanavin@linux.intel.com
> Date: Wed, 27 Apr 2016 15:38:01 +0300
> 
> On 04/26/2016 11:05 AM, Zhenhua Luo wrote:
> > Any ideas as to why "qemu-ppc64 crashes out immediately"?
> >
> > I can confirm the build ends in a segfault when I tried building
> > gobject-introspection for the t1042d4rdb-64b machine.
> >
> > */[Luo Zhenhua-B19537] This is a gobject-introspection support issue of
> > QEMU PPC64, the fix is not available now, you can use the following
> > workaround to bypass the issue. /*
> >
> > */http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18/*
> 
> I'm afraid disabling introspection data is not an acceptable solution 
> for Chris, because he does want to have that data.
> 
> Also, I'll send a fix to disable building of introspection data on all 
> ppc64 machines for now.
> 
> Alex

Thanks Alex.
This is not urgent and with this processor there is the option of using 32-bit mode.  So if the new commit fixes the 32-bit machine then that would be an acceptable alternative for now.
I like to fix things so I am curious about the qemu-ppc64 crash but realise I can't afford to spend much time on it!
Regards,Chris
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1874 bytes --]