* gtk+ native recipe question @ 2012-10-30 18:56 T.Michael Turney 2012-10-31 14:07 ` Paul Eggleton 0 siblings, 1 reply; 5+ messages in thread From: T.Michael Turney @ 2012-10-30 18:56 UTC (permalink / raw) To: Openembedded-core 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gtk+ native recipe question 2012-10-30 18:56 gtk+ native recipe question T.Michael Turney @ 2012-10-31 14:07 ` Paul Eggleton 2012-10-31 19:57 ` T.Michael Turney 0 siblings, 1 reply; 5+ messages in thread From: Paul Eggleton @ 2012-10-31 14:07 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gtk+ native recipe question 2012-10-31 14:07 ` Paul Eggleton @ 2012-10-31 19:57 ` T.Michael Turney 2012-10-31 22:31 ` Paul Eggleton 0 siblings, 1 reply; 5+ messages in thread From: T.Michael Turney @ 2012-10-31 19:57 UTC (permalink / raw) To: Paul Eggleton; +Cc: openembedded-core 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gtk+ native recipe question 2012-10-31 19:57 ` T.Michael Turney @ 2012-10-31 22:31 ` Paul Eggleton 2012-10-31 22:51 ` Paul Eggleton 0 siblings, 1 reply; 5+ messages in thread From: Paul Eggleton @ 2012-10-31 22:31 UTC (permalink / raw) To: T.Michael Turney; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gtk+ native recipe question 2012-10-31 22:31 ` Paul Eggleton @ 2012-10-31 22:51 ` Paul Eggleton 0 siblings, 0 replies; 5+ messages in thread From: Paul Eggleton @ 2012-10-31 22:51 UTC (permalink / raw) To: T.Michael Turney; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-31 23:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-30 18:56 gtk+ native recipe question T.Michael Turney 2012-10-31 14:07 ` Paul Eggleton 2012-10-31 19:57 ` T.Michael Turney 2012-10-31 22:31 ` Paul Eggleton 2012-10-31 22:51 ` Paul Eggleton
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.