gtk+ native recipe question

gtk+ native recipe question

[T.Michael Turney]

My first post, chose -core over -devel somewhat arbitrarily as I don't  
understand distinction of OE-classic yet.

In order to get an existing OE system (builds on Fedora) to build correctly
on 64-bit Ubuntu 12.04 I had to modify a number of recipe files.

In order to get native gtk+ to build I had to add no-demos.patch
to SRC_URI_append.  The patch file already existed in recipes tree
but wasn't being referenced in the .bb file.

Second change was adding glib-2.0-native to DEPEND_virtclass-native in  
same file.

Problem was manifested with unresolved reference to g_bytes_unref when
building gtk+ native.  Ubuntu 12.04 has more recent glib install than in
OE project I'm building and g_bytes_unref is visible in host glib but not
OE version.

With this change and a few other similar minor changes in .bb files, the
system builds.  However, the bitbake build line has to be invoked twice.

For example, let's say I'm building foo-image and foo1-image, and I run:

bitbake foo-image foo1-image

This command fails building gtk+ native.  I re-run exact same command:

bitbake foo-image foo1-image

and this time gtk+ native builds correctly and whole system builds.

Any suggestions on what I should be looking at to get the dependency info
correct so first build doesn't fail?
Cheers,
T.mike

Re: gtk+ native recipe question

[Paul Eggleton]

Hi there,

On Tuesday 30 October 2012 11:56:15 T.Michael Turney wrote:
> My first post, chose -core over -devel somewhat arbitrarily as I don't
> understand distinction of OE-classic yet.

Basically, OE-Classic is largely unmaintained (aside from critical updates to 
the 2011.3-maintenance branch) and should not be used for new work - use OE-
Core for that instead. So you're on the right path already :)

> In order to get an existing OE system (builds on Fedora) to build correctly
> on 64-bit Ubuntu 12.04 I had to modify a number of recipe files.

That's definitely not expected...

> In order to get native gtk+ to build I had to add no-demos.patch
> to SRC_URI_append.  The patch file already existed in recipes tree
> but wasn't being referenced in the .bb file.
> 
> Second change was adding glib-2.0-native to DEPEND_virtclass-native in
> same file.

So, the version in master and the danny branch (most recent stable, just 
branched the other day) already includes this. Are you using a different 
branch/release?

> Problem was manifested with unresolved reference to g_bytes_unref when
> building gtk+ native.  Ubuntu 12.04 has more recent glib install than in
> OE project I'm building and g_bytes_unref is visible in host glib but not
> OE version.
> 
> With this change and a few other similar minor changes in .bb files, the
> system builds.  However, the bitbake build line has to be invoked twice.
> 
> For example, let's say I'm building foo-image and foo1-image, and I run:
> 
> bitbake foo-image foo1-image
> 
> This command fails building gtk+ native.  

Fails how? Can you mention the actual error you're receiving?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: gtk+ native recipe question

[T.Michael Turney]

Quoting Paul Eggleton <paul.eggleton@linux.intel.com>:

> Hi there,
>
> On Tuesday 30 October 2012 11:56:15 T.Michael Turney wrote:
>> My first post, chose -core over -devel somewhat arbitrarily as I don't
>> understand distinction of OE-classic yet.
>
> Basically, OE-Classic is largely unmaintained (aside from critical updates to
> the 2011.3-maintenance branch) and should not be used for new work - use OE-
> Core for that instead. So you're on the right path already :)
>
>> In order to get an existing OE system (builds on Fedora) to build correctly
>> on 64-bit Ubuntu 12.04 I had to modify a number of recipe files.
>
> That's definitely not expected...

These package recipes were modified for reason:
gtk+  : issue mentioned in this post, pulling in host glib
orc   : bad code in examples, honestly no idea how it built on Fedora
pango : add libxrender-native to DEPENDS_virtclass-native
perl  : change glibpth to reference Ubuntu 64-bit library paths
soci  : added configure.in.patch to correctly set SQLITE3_DIRS, as  
with orc, no idea how this built on Fedora

>
>> In order to get native gtk+ to build I had to add no-demos.patch
>> to SRC_URI_append.  The patch file already existed in recipes tree
>> but wasn't being referenced in the .bb file.
>>
>> Second change was adding glib-2.0-native to DEPEND_virtclass-native in
>> same file.
>
> So, the version in master and the danny branch (most recent stable, just
> branched the other day) already includes this. Are you using a different
> branch/release?

We took snapshot at beginning of 2011, last commit in git tree prior
to our mods is:

af8541c1ba14f5b075f5fdf93fc7f0689656432c
Author: Alex Ferguson <thoughtmonster@gmail.com>  2011-01-31 08:43:44

I realize this somewhat limits interest in this issue, hence my original
query to just better understand the build system and an idea of what I
should be looking at in terms of bitbake/openembedded dependencies.

>
>> Problem was manifested with unresolved reference to g_bytes_unref when
>> building gtk+ native.  Ubuntu 12.04 has more recent glib install than in
>> OE project I'm building and g_bytes_unref is visible in host glib but not
>> OE version.
>>
>> With this change and a few other similar minor changes in .bb files, the
>> system builds.  However, the bitbake build line has to be invoked twice.
>>
>> For example, let's say I'm building foo-image and foo1-image, and I run:
>>
>> bitbake foo-image foo1-image
>>
>> This command fails building gtk+ native.
>
> Fails how? Can you mention the actual error you're receiving?

This is tail-end of build log that fails, with last command-line  
issued from bitbake...

| x86_64-linux-libtool: link: gcc -shared  -fPIC -DPIC   
.libs/gtkimcontextxim.o .libs/imxim.o   -Wl,-rpath  
-Wl,home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk-pixbuf/.libs -Wl,-rpath -Wl,home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk/.libs -Wl,-rpath -Wl,home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gtk/.libs -Wl,-rpath -Wl,/home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath -Wl,home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib -L/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk-pixbuf/.libs -L/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk/.libs -L/home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib ../../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -L=home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib -L//home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib ../../gdk/.libs/libgdk-x11-2.0.so -L=/usr/lib ../../gtk/.libs/libgtk-x11-2.0.so /home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libXext.so /home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpangocairo-1.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libatk-1.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libcairo.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpixman-1.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpng12.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libX11.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libxcb.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpthread-stubs.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libXau.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libXdmcp.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libXrender.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libgio-2.0.so -lresolv //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpangoft2-1.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libpango-1.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libfontconfig.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libfreetype.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libz.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libexpat.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libgobject-2.0.so //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libgmodule-2.0.so -ldl //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libgthread-2.0.so -lpthread -lrt //home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib/libglib-2.0.so -lm  -O2 -Wl,-rpath-link -Wl,/home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath -Wl,/home/tturney/gitrepos/bengalbb/tmp/sysroots/x86_64-linux/usr/lib -Wl,-O1 -pthread   -pthread -Wl,-soname -Wl,im-xim.so -o  
.libs/im-xim.so
| x86_64-linux-libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln  
-s "../im-xim.la" "im-xim.la" )
| ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la  
im-cyrillic-translit.la  im-inuktitut.la im-ipa.la im-multipress.la  
im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la  > gtk.immodules
|  
/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gtk/.libs/lt-gtk-query-immodules-2.0: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0: undefined symbol:  
g_bytes_unref
| make[3]: *** [gtk.immodules] Error 127
| make[3]: Leaving directory  
`/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/modules/input'
| make[2]: *** [all-recursive] Error 1
| make[2]: Leaving directory  
`/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/modules'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory  
`/home/tturney/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1'
| make: *** [all] Error 2
| FATAL: oe_runmake failed
| ERROR: Function do_compile failed
NOTE: package gtk+-native-2.20.1-r10.4: task do_compile: Failed
ERROR: TaskFailed event exception, aborting
ERROR: Build of  
virtual:native:/home/tturney/gitrepos/bengalbb/openembedded-dev/recipes/gtk+/gtk+_2.20.1.bb do_compile  
failed
ERROR: Task 1918  
(virtual:native:/home/tturney/gitrepos/bengalbb/openembedded-dev/recipes/gtk+/gtk+_2.20.1.bb, do_compile) failed with  
256
ERROR:  
'virtual:native:/home/tturney/gitrepos/bengalbb/openembedded-dev/recipes/gtk+/gtk+_2.20.1.bb'  
failed
ERROR:  
'virtual:native:/home/tturney/gitrepos/bengalbb/openembedded-dev/recipes/gtk+/gtk+_2.20.1.bb'  
failed
tturney@twt20274:~/gitrepos/bengalbb$

I am assuming the collision comes from...
tturney@twt20274:~/gitrepos/bengalbb/tmp/work/x86_64-linux/gtk+-native-2.20.1-r10.4/gtk+-2.20.1/gtk/.libs$ ldd  
lt-gtk-query-immodules-2.0
         ...
	libgdk_pixbuf-2.0.so.0 =>  
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fc24a80d000)
         ...

tturney@twt20274:/usr/lib/x86_64-linux-gnu$ ldd libgdk_pixbuf-2.0.so.0
         ...
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0  
(0x00007f77f0ce7000)
         ...

libglib-2.0.so.0: symbolic link to `libglib-2.0.so.0.3200.3'

Host version of glib is newer than OE version and has g_bytes_unref.

What is not clear to me yet is why the OE bb recipe for gtk+-native is  
falling back on the host version of glib the first time through the  
build.

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>

Re: gtk+ native recipe question

[Paul Eggleton]

On Wednesday 31 October 2012 12:57:42 T.Michael Turney wrote:
> These package recipes were modified for reason:
> gtk+  : issue mentioned in this post, pulling in host glib

Looks like this one has already been fixed.

> orc   : bad code in examples, honestly no idea how it built on Fedora

Not sure about this one; it's not one that I build regularly myself, perhaps 
someone else can shed some light but one suspects you'd need to be more 
specific about the actual error.

> pango : add libxrender-native to DEPENDS_virtclass-native

libxrender(-native) does seem to be missing in DEPENDS(_virtclass-native) and 
the configure script does refer to it. I suspect we haven't hit it often due to 
the order of dependencies being built that themselves do have libxrender in 
DEPENDS, but we still need to fix it in the pango recipe.

> perl  : change glibpth to reference Ubuntu 64-bit library paths

We've fixed a lot of perl issues since early 2011. Searching through, I think 
that this was fixed in March 2011.

> soci  : added configure.in.patch to correctly set SQLITE3_DIRS, as
> with orc, no idea how this built on Fedora

soci? I can't seem to find a recipe here for that - is that a recipe you have 
created?

> > So, the version in master and the danny branch (most recent stable, just
> > branched the other day) already includes this. Are you using a different
> > branch/release?
> 
> We took snapshot at beginning of 2011, last commit in git tree prior
> to our mods is:
> 
> af8541c1ba14f5b075f5fdf93fc7f0689656432c
> Author: Alex Ferguson <thoughtmonster@gmail.com>  2011-01-31 08:43:44
> 
> I realize this somewhat limits interest in this issue, hence my original
> query to just better understand the build system and an idea of what I
> should be looking at in terms of bitbake/openembedded dependencies.

I would strongly recommend using one of the stable branches / tags rather than 
just taking an arbitrary snapshot, in conjunction with an appropriate stable 
release of bitbake. Do otherwise and it becomes more difficult for us to 
support. FWIW, the denzil branch is the oldest branch which we actively 
support now, although folks in the community are welcome to continue support 
for older stable branches if they wish.

It's also worth noting that Ubuntu 12.04 wasn't released until April 2012, so 
it's not surprising that you would find issues with it as a host for the 
metadata that's only as up-to-date as early 2011.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: gtk+ native recipe question

[Paul Eggleton]

On Wednesday 31 October 2012 22:31:44 Paul Eggleton wrote:
> On Wednesday 31 October 2012 12:57:42 T.Michael Turney wrote:
> > These package recipes were modified for reason:
> > gtk+  : issue mentioned in this post, pulling in host glib
> 
> Looks like this one has already been fixed.
> 
> > orc   : bad code in examples, honestly no idea how it built on Fedora
> 
> Not sure about this one; it's not one that I build regularly myself, perhaps
> someone else can shed some light but one suspects you'd need to be more
> specific about the actual error.
> 
> > pango : add libxrender-native to DEPENDS_virtclass-native
> 
> libxrender(-native) does seem to be missing in DEPENDS(_virtclass-native)
> and the configure script does refer to it. I suspect we haven't hit it
> often due to the order of dependencies being built that themselves do have
> libxrender in DEPENDS, but we still need to fix it in the pango recipe.
> 
> > perl  : change glibpth to reference Ubuntu 64-bit library paths
> 
> We've fixed a lot of perl issues since early 2011. Searching through, I
> think that this was fixed in March 2011.
> 
> > soci  : added configure.in.patch to correctly set SQLITE3_DIRS, as
> > with orc, no idea how this built on Fedora
> 
> soci? I can't seem to find a recipe here for that - is that a recipe you
> have created?
> 
> > > So, the version in master and the danny branch (most recent stable, just
> > > branched the other day) already includes this. Are you using a different
> > > branch/release?
> > 
> > We took snapshot at beginning of 2011, last commit in git tree prior
> > to our mods is:
> > 
> > af8541c1ba14f5b075f5fdf93fc7f0689656432c
> > Author: Alex Ferguson <thoughtmonster@gmail.com>  2011-01-31 08:43:44
> > 
> > I realize this somewhat limits interest in this issue, hence my original
> > query to just better understand the build system and an idea of what I
> > should be looking at in terms of bitbake/openembedded dependencies.
> 
> I would strongly recommend using one of the stable branches / tags rather
> than just taking an arbitrary snapshot, in conjunction with an appropriate
> stable release of bitbake. Do otherwise and it becomes more difficult for
> us to support. FWIW, the denzil branch is the oldest branch which we
> actively support now, although folks in the community are welcome to
> continue support for older stable branches if they wish.

What I had neglected to do was to check where the revision you pointed to, 
af8541c1ba14f5b075f5fdf93fc7f0689656432c, was actually from. This is an OE-
Classic revision, so knowing that I can understand you having taken a snapshot 
at a particular date as this was a recommended approach in the old OE-Classic 
days.

If you've not seen this already you may find it informative:

http://www.openembedded.org/wiki/OpenEmbedded-Core

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre