Re: gobject-introspection build failure

[Colin Helliwell <colin helliwell ln-systems com>]

> On 30 March 2017 at 16:09 Thomas Haller <thaller redhat com> wrote:
>
> On Thu, 2017-03-30 at 11:07 +0100, colin helliwell ln-systems com
> wrote:
>
> > I was able to build NM 1.4.2 with G-I enabled, and have now moved up
> > to
> > 1.8/master.
> > But hitting a build failure (cross-compiling, in Yocto):
...
> > > "/usr/bin/python" \
> > >  ../git/libnm/generate-setting-docs.py \
> > >  --gir ./libnm/NM-1.0.gir \
> > >  --output libnm/nm-property-docs.xml
> > >
> > > ** (process:13095): WARNING **: Failed to load shared library
> > > 'libnm.so.0'
> >
> > referenced by the typelib: libnm.so.0: wrong ELF class: ELFCLASS32
> >
> > > ../git/libnm/generate-setting-docs.py:217: Warning: cannot retrieve
> > > class
> >
> > for invalid (unclassed) type 'void'
> >
> > > setting = new_func()
> > > Traceback (most recent call last):
> > >  File "../git/libnm/generate-setting-docs.py", line 217, in
> > >
> > >
> > >  setting = new_func()
> > > TypeError: could not get a reference to type class
> > > make[2]: *** [libnm/nm-property-docs.xml] Error 1
> > > make[2]: *** Deleting file `libnm/nm-property-docs.xml'
> > > make[2]: Leaving directory
> >
> > `/home/colin/100051-karo/fsl-community-bsp/build/tmp/work/cortexa9hf-
> > neon-po
> > ky-linux-gnueabi/networkmanager/1.8-r0/build'
> >
> > I imagine something is objecting to the cross-compiled library, but
> > I've not
> > been able to figure out who is actually throwing the error. (A python
> > module?)
>
> The python script generate-setting-docs.py uses pygobject to eventually
> load libnm.so.
>
> Seems like the wrong libnm.so is loaded.
>
> Maybe it helps to set "LD_DEBUG=all" to see from where the shared
> library comes?

I'll look into hooking that in. But, looking at where the source & build are, there is only one libnm.so*
library anyway (excluding the symlinks):

networkmanager/1.8-r0/build/libnm/.libs/libnm.so.0.1.0: ELF 32-bit LSB  shared object, ARM, EABI5 version 1 
(SYSV), dynamically linked, BuildID[sha1]=c769030b4b08da970aef500cc44a1dd8e7456c42, not stripped


...
> > I also notice that 'ldd' is being used above (to check for address
> > sanitizer
> > being enabled?) - but this isn't going to work for cross-compiling;
> > needs
> > some form of modification e.g. '[cross-tools]-readelf -a'?
>
> patches welcome :)

Lol - ok will look into it.