I tried building "core-image-sato" for target: x86_64 and arm but none was successful. After a round of discussion on #yocto it became clear to be a openjade build issue on my workstation, which is running Ubuntu 12.04 (x86_64). Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux The error goes as follows: | make[2]: *** [helpers.html] Error 127 | jade: symbol lookup error: /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE The complete log.do_compile is uploaded to pastebin (http://pastebin.com/P189gBPJ ). It appears that the openjade v1.3+ has an issue being built on x86_64 host due to a shared lib linking issue (libogrove.so), which was fixed when using static linking in the configuration step. I made the following patch (http://pastebin.com/cUb1x2Qj) fixed the issue and things go smoothly.
do_install uploaded http://pastebin.com/erKaFN9L
I can reproduce this on a 32bit host.
Hello Neeraj Sharma, Could you please attach the output of ldd openjade (binary inside installed by openjade-native). Thanks
(In reply to comment #3) > Hello Neeraj Sharma, > > Could you please attach the output of ldd openjade (binary inside installed > by openjade-native). > > Thanks It was an issue with gcc. Seems like an ubuntu update did the trick. ag
(In reply to comment #4) > (In reply to comment #3) > > Hello Neeraj Sharma, > > > > Could you please attach the output of ldd openjade (binary inside installed > > by openjade-native). > > > > Thanks > > It was an issue with gcc. Seems like an ubuntu update did the trick. > > ag Ignore this comment. This problem is still reproducible. Hope for a feedback from Neeraj Sharma with a ldd output. Andrei
I could NOT reproduce this issue on my Ubuntu 12.04 machine! bitbake openjade-native Loading cache: 100% |###########################################| ETA: 00:00:00 Loaded 1964 entries from dependency cache. Build Configuration: BB_VERSION = "1.15.3" TARGET_ARCH = "x86_64" TARGET_OS = "linux" MACHINE = "qemux86-64" DISTRO = "poky" DISTRO_VERSION = "1.2+snapshot-20120918" TUNE_FEATURES = "m64" TARGET_FPU = "" meta meta-yocto meta-yocto-bsp = "mut:a2d467e9380af0fbe5c21980b1415b9c69878c02" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 77 tasks of which 67 didn't need to be rerun and all succeeded. sgw@yujin:/intel/poky/builds/multilib$ uname -a Linux yujin 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux For Reference, here is my ldd output: sgw@yujin:/intel/poky/builds/multilib$ ldd tmp/sysroots/x86_64-linux/usr/bin/openjade linux-vdso.so.1 => (0x00007fff392c1000) libostyle.so.0 => /intel/poky/builds/multilib/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libostyle.so.0 (0x00007f89fe26a000) libospgrove.so.0 => /intel/poky/builds/multilib/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libospgrove.so.0 (0x00007f89fdfdb000) libogrove.so.0 => /intel/poky/builds/multilib/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libogrove.so.0 (0x00007f89fddc9000) libosp.so.5 => /intel/poky/builds/multilib/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libosp.so.5 (0x00007f89fd9d5000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f89fd7a3000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f89fd4a3000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f89fd28d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f89fcecf000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f89fcbd5000) /lib64/ld-linux-x86-64.so.2 (0x00007f89fe6da000) Andrei, please also post your bad ldd, seems like your working on this issue
The problem in my case in most probably in Neeraj's case too is that openjade is not linked to libogrove. Any idea why? ldd openjade linux-gate.so.1 => (0xb76ec000) libostyle.so.0 => /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/usr/lib/libostyle.so.0 (0xb74ea000) libospgrove.so.0 => /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/usr/lib/libospgrove.so.0 (0xb7485000) libosp.so.5 => /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/usr/lib/libosp.so.5 (0xb72aa000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7276000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7191000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7173000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6fcd000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6fa1000) /lib/ld-linux.so.2 (0xb76ed000)
(In reply to comment #7) > The problem in my case in most probably in Neeraj's case too is that > openjade is not linked to libogrove. Any idea why? > > ldd openjade > linux-gate.so.1 => (0xb76ec000) > libostyle.so.0 => > /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/ > usr/lib/libostyle.so.0 (0xb74ea000) > libospgrove.so.0 => > /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/ > usr/lib/libospgrove.so.0 (0xb7485000) > libosp.so.5 => > /home/agherzan/work/personal/yocto/2012-09-06-rpi/tmp/sysroots/i686-linux/ > usr/lib/libosp.so.5 (0xb72aa000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7276000) > libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7191000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7173000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6fcd000) > libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6fa1000) > /lib/ld-linux.so.2 (0xb76ed000) I dont have my ldd output handy, but it did look similar. As I remember the issue is probably with gcc where its unable to detect that the shared library libogrove.so is also to be linked to openjade (thats why you dont see that in your ldd out either). One way to get around this issue is to statically link openjade so the compiler will figure out that libogrove.a is required and do the needful. What was strange, though I was unable to spend much time (was out-of-town for a while) is that gcc just sees libospgrove and not libogrove when linking openjade binary to its shared libs.
(In reply to comment #8) > What was strange, though I was unable to spend much time (was out-of-town > for a while) is that gcc just sees libospgrove and not libogrove when > linking openjade binary to its shared libs. For sample fix look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=2972#c0 or specifically http://pastebin.com/cUb1x2Qj I know that it do not solve the issue, but did help me in getting across the nagging issue for the time.
We tried on our 12.04 and couldn't reproduce the issue so mark it as worksforme and won't fix, if you still do see it, please reopen
Jessica, sorry to disappoint you, but I have a case here where Jade wont link to libgrove. I think it happens under special circumstances because a friend of mine has the same setup as I and he didn't run in this issue. Here is my output: | make[2]: Entering directory `/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc/man' | make[2]: Nothing to be done for `all'. | make[2]: Leaving directory `/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc/man' | Making all in HTML | make[2]: Entering directory `/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc/HTML' | SGML_CATALOG_FILES=/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/etc/sgml/catalog \ | SGML_SEARCH_PATH=../..:../../doc:.. \ | jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ | -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml | SGML_CATALOG_FILES=/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/etc/sgml/catalog \ | SGML_SEARCH_PATH=../..:../../doc:.. \ | jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ | -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml | SGML_CATALOG_FILES=/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/etc/sgml/catalog \ | SGML_SEARCH_PATH=../..:../../doc:.. \ | jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ | -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml | SGML_CATALOG_FILES=/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/etc/sgml/catalog \ | SGML_SEARCH_PATH=../..:../../doc:.. \ | jade -t sgml -i html -d ../../docbook-utils.dsl\#html \ | -V '%use-id-as-filename%' ../../doc/docbook-utils.sgml | jade: symbol lookup error: /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE | make[2]: *** [backend-spec.html] Error 127 | make[2]: *** Waiting for unfinished jobs.... | jade: symbol lookup error: /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE | make[2]: *** [docbook2texi.html] Error 127 | jade: symbol lookup error: /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE | jade: symbol lookup error: /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE | make[2]: *** [api.html] Error 127 | make[2]: *** [docbook2man.html] Error 127 | make[2]: Leaving directory `/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc/HTML' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc' | make: *** [all-recursive] Error 1 | ERROR: oe_runmake failed | ERROR: Function failed: do_compile (see /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/work/i686-linux/docbook-utils-native-0.6.14-r3/temp/log.do_compile.2686 for further information) ERROR: Task 2511 (/home/blabla/yocto/test/poky_danny/meta/recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 2098 tasks of which 2071 didn't need to be rerun and 1 failed. Waiting for 0 running tasks to finish:
It seems that libgrove is linked to openjade: libostyle.so.0 => /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libostyle.so.0 (0xb758e000) libospgrove.so.0 => /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0 (0xb7529000) libosp.so.5 => /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/libosp.so.5 (0xb734e000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7311000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb722c000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb720e000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7063000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7037000) /lib/ld-linux.so.2 (0xb7790000) So the problem should be in docbook-utils.
(In reply to comment #12) > It seems that libgrove is linked to openjade: > libostyle.so.0 => > /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/ > beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/ > libostyle.so.0 (0xb758e000) > libospgrove.so.0 => > /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/ > beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/ > libospgrove.so.0 (0xb7529000) > libosp.so.5 => > /media/d8fab3a6-4a27-4050-a2c3-d58b47cf0e82/poky/yocto/test/mybuilds/ > beagleboard-core-image-bbv/tmp/sysroots/i686-linux/usr/bin/../../usr/lib/ > libosp.so.5 (0xb734e000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7311000) > libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb722c000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb720e000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7063000) > libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7037000) > /lib/ld-linux.so.2 (0xb7790000) > > So the problem should be in docbook-utils. Forge the last senttence. It is newly build jade
(In reply to comment #10) > We tried on our 12.04 and couldn't reproduce the issue so mark it as > worksforme and won't fix, if you still do see it, please reopen I have done now a test on a new LUbuntu 12.10 32bit system. And it failed again at the exact same linking process. I use Poky danny release. Any ideas? I use now the static build patch but this is not the solution.
I want to confirm your setup and get a clean set of reproduction steps. This issue originally was x86-64, but you mention a 32bit system. Can you please give the complete setup (including any config files, which layers you included), what target are you building for what's your host configuration? If you can reduce it to a clean vs sstate build for a given target like openjade-native that would be very helpful.
(In reply to comment #15) > I want to confirm your setup and get a clean set of reproduction steps. > This issue originally was x86-64, but you mention a 32bit system. > > Can you please give the complete setup (including any config files, which > layers you included), what target are you building for what's your host > configuration? > > If you can reduce it to a clean vs sstate build for a given target like > openjade-native that would be very helpful. I made the following test. I have a own recipe which is based on core-image-x11.bb I tested the recipe whith LUbuntu12.04 and LUbuntu12.10 on a vmware machine and native. I tried to run the recipe 5 times totally fresh from scratch. I'm always received the error about openjade-native. Then I installed the staticlinking patch which was mentioned here and it worked. The strange thing is that a frind of mine used the same scripts under Ubuntu12.10 and it ran through without the staticlinking patch. So it seems to me that this problem happens under special circumstances eg. special settings, certain packages installed on the host. So when you install a fresh LUbuntu 12.10 and let core-image-x11.bb run the error should appear as well. I will do some further tests soon.
Can you confirm which updates you'd applied (not not applied to the basic 12.04 install? I've tried to reproduce this on 12.10 here and it doesn't happen. I do apply the Ubuntu updates to the system though.
(In reply to comment #17) > Can you confirm which updates you'd applied (not not applied to the basic > 12.04 install? I've tried to reproduce this on 12.10 here and it doesn't > happen. I do apply the Ubuntu updates to the system though. It only happens on a slow notebook with LUbuntu 12.10. I also have test it on LUbuntu 12.10 on a faster newer Notebook. There I haven 't had to install the patch. It's a really strange bug. Also our build server has no problem to build openjade and docbook-utils
I am dropping this to normal since it seems to be a limited case
Any more progress on reproducing this? If not, I am going to close it out
Since there is no good reproducer for this bug, I am going to close it out. If we can get a solid reproducer, please reopen as needed.
I stepped over this bug on Ubuntu 14.04 on a x86_64 machine using yocto daisy. Just "bitbake -k docbook-utils-native" should be enough to reproduce, but, you need to use the gold linker instead of GNU ld. With GNU ld it worked just fine. gold linker is getting more popular everyday, so this might be a problem in the future. For people like me working with Chromium browser, you get visible speedups on linking time.
Can you please provide a little more information about your failure and your full setup? I am running on a 13.10 machine, I set up LD to be -> ld.gold and I set the DISTRO_FEATURE ld-is-gold and did the bitbake docbook-utils-native and it succeeded.
(In reply to comment #23) > Can you please provide a little more information about your failure and your > full setup? I am running on a 13.10 machine, I set up LD to be -> ld.gold > and > I set the DISTRO_FEATURE ld-is-gold and did the bitbake docbook-utils-native > and it succeeded. I'm new to Yocto and didn't know about "ld-is-gold". Gonna try it again here. Previously, I was just running with the default configuration unchanged.
Just tried here with this feature flag and did not work. :((In reply to comment #24) > (In reply to comment #23) > > Can you please provide a little more information about your failure and your > > full setup? I am running on a 13.10 machine, I set up LD to be -> ld.gold > > and > > I set the DISTRO_FEATURE ld-is-gold and did the bitbake docbook-utils-native > > and it succeeded. > > I'm new to Yocto and didn't know about "ld-is-gold". Gonna try it again > here. Previously, I was just running with the default configuration > unchanged. DISTRO_FEATURES_append = " ld-is-gold" and it did not work for me. I building on a Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz running Ubuntu 14.04 64-bits, but I was able to reproduce on the same machine running Ubuntu 13.10 64-bits. Ubuntu changed the way to set gold as the default linker. Previously it would do a trick by renaming the binaries on the post install hooks when installing gold. Now, apparently, both are shipped together on the binutils package with GNU ld as the default. What I'm doing to enable gold is just making a symlink on /usr/local/bin/ld -> /usr/bin/gold. Has been working so far for building other things.
Ok, I have been able to spend some time and reproduce this, it is indeed a host gold related issue, I can reproduce this with my Ubuntu 13.10 machine. For now, I would recommend a work around of using ld.bfd until we can get a toolchain person look at this in more detail. There seems to be a linking problem in the openjade-native with libospgrove.so and libogrove.so, the missing symbol _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE is in libogrove, but an ldd of both jade and libospgrove do not show the dependecny on libogrove. Looking at the link command, libogrove is passed as a library, so the issue is probably in gold since this works correctly with ld.bfd
I can confirm that this is indeed a Gold linker bug, just as Saul said, the linker fails to create the dependency for libogrove.so, the link command is correct and substituting ld.gold -> ld.bfd on it fixes the issue, I also thought it could be distro related, perhaps the binutils package for Ubuntu was the problem since I'm using Linux Mint 17 (based on Ubuntu 14.04), so I compiled Gold from source, but had no success fixing the problem, the best workaround would be to use ld.bfd or in any case use static libraries. I am gonna close this for now.
(In reply to comment #26) I can still reproduce this with gold. Are you absolutely sure that the right library name was passed and ended up in the linker command line? I have seen tons of problems where ld.bfd pulled in transitive dependencies, which gold doesn't do. I have not once seen gold fail to link to a library explicitly passed in. Longer explanation of the scenario: YourApp is explicitly linked against libA which requires libB. ld.bfd will helpfully insert libB into the list of libraries required by YourApp. ld.gold will only insert what you tell it to. This is not considered to be a bug by, well, at least the gold authors and myself :)
This has now been worked around via the static link approach in the core, so alter the resolution.