Bug 10102

Summary: gdk-pixbuf-native missing dependency on pcre needed by glib-2.0-native
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Martin Jansa <Martin.Jansa>
Component: graphicsAssignee: Ross Burton <ross.burton>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher, richard.purdie, sgw
Version: 2.1   
Target Milestone: 2.2 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Martin Jansa 2016-08-09 10:59:56 UTC
This is with Yocto 2.1 Krogoth.

Causing following ugly exception when postinst is executed in rootfs:

/home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
WARNING: exit code 1 from a shell command.
ERROR: Execution of event handler 'base_eventhandler' failed
Traceback (most recent call last):
  File "/home/jenkins/workspace/luneos-stable/webos-ports/openembedded-core/meta/classes/base.bbclass", line 259, in base_eventhandler(e=<bb.runqueue.sceneQueueComplete object at 0x7f128d4686d0>):
                 bb.debug(1, "Executing SceneQueue Completion commands: %s" % "\n".join(cmds))
    >            bb.build.exec_func("completion_function", e.data)
                 os.remove(completions)
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/build.py", line 234, in exec_func(func='completion_function', d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>, dirs=None, pythonexception=False):
             else:
    >            exec_func_shell(func, d, runfile, cwd=adir)
     
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/build.py", line 382, in exec_func_shell(func='completion_function', d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>, runfile='/home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/work/armv7a-neon-webos-linux-gnueabi/defaultpkgname/1.0-r0/temp/run.completion_function.17768', cwd='/home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/work/armv7a-neon-webos-linux-gnueabi/defaultpkgname/1.0-r0/defaultpkgname-1.0'):
                     logfn = d.getVar('BB_LOGFILE', True)
    >                raise FuncFailed(func, logfn)
             finally:
FuncFailed: Function failed: completion_function

ERROR: An uncaught exception occured in runqueue, please see the failure below:
ERROR: Running idle function
Traceback (most recent call last):
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/event.py", line 110, in fire_class_handlers(event=<bb.runqueue.sceneQueueComplete object at 0x7f128d4686d0>, d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>):
                         continue
    >            execute_handler(name, handler, event, d)
     
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/event.py", line 82, in execute_handler(name='base_eventhandler', handler=<function base_eventhandler at 0x7f129b1412a8>, event=<bb.runqueue.sceneQueueComplete object at 0x7f128d4686d0>, d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>):
         try:
    >        ret = handler(event)
         except (bb.parse.SkipRecipe, bb.BBHandledException):
  File "/home/jenkins/workspace/luneos-stable/webos-ports/openembedded-core/meta/classes/base.bbclass", line 259, in base_eventhandler(e=<bb.runqueue.sceneQueueComplete object at 0x7f128d4686d0>):
                 bb.debug(1, "Executing SceneQueue Completion commands: %s" % "\n".join(cmds))
    >            bb.build.exec_func("completion_function", e.data)
                 os.remove(completions)
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/build.py", line 234, in exec_func(func='completion_function', d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>, dirs=None, pythonexception=False):
             else:
    >            exec_func_shell(func, d, runfile, cwd=adir)
     
  File "/home/jenkins/workspace/luneos-stable/webos-ports/bitbake/lib/bb/build.py", line 382, in exec_func_shell(func='completion_function', d=<bb.data_smart.DataSmart object at 0x7f129aef2dd0>, runfile='/home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/work/armv7a-neon-webos-linux-gnueabi/defaultpkgname/1.0-r0/temp/run.completion_function.17768', cwd='/home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/work/armv7a-neon-webos-linux-gnueabi/defaultpkgname/1.0-r0/defaultpkgname-1.0'):
                     logfn = d.getVar('BB_LOGFILE', True)
    >                raise FuncFailed(func, logfn)
             finally:
FuncFailed: Function failed: completion_function

Command exited with non-zero status 1


OE qemux86@luneos ~/workspace/luneos-stable/webos-ports $ ldd /home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders.real
        linux-vdso.so.1 =>  (0x00007ffea99fa000)
        libgmodule-2.0.so.0 => /home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/../libgmodule-2.0.so.0 (0x00007f1d8db26000)
        libgobject-2.0.so.0 => /home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/../libgobject-2.0.so.0 (0x00007f1d8d8d5000)
        libglib-2.0.so.0 => /home/jenkins/workspace/luneos-stable/webos-ports/tmp-glibc/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/../libglib-2.0.so.0 (0x00007f1d8d5c9000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1d8d3ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1d8cfe6000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1d8cde2000)
        libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f1d8cbda000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1d8dd2a000)
        libpcre.so.1 => not found
Comment 1 Martin Jansa 2016-08-09 11:48:50 UTC
Possibly caused by sstate optimalization discussed here:
http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html
?
Comment 2 Martin Jansa 2016-08-09 11:55:22 UTC
There is dependency only from glib-2.0-native.do_configure, but that's probably skipped and gdk-pixbuf-native from sstate doesn't work because libpcre-native.do_populate_sysroot wasn't executed.

OE qemux86@luneos ~/workspace/luneos-stable/webos-ports $ grep " -> \"libpcre-native" task-depends.dot 
"libpcre-native.do_install" -> "libpcre-native.do_compile"
"rpm-native.do_configure" -> "libpcre-native.do_populate_sysroot"
"libpcre-native.do_unpack" -> "libpcre-native.do_fetch"
"libpcre-native.do_build" -> "libpcre-native.do_populate_lic"
"libpcre-native.do_build" -> "libpcre-native.do_populate_sysroot"
"libpcre-native.do_configure" -> "libpcre-native.do_patch"
"libpcre-native.do_populate_sysroot" -> "libpcre-native.do_install"
"luneos-dev-image.do_rootfs" -> "libpcre-native.do_populate_lic"
"libpcre-native.do_compile" -> "libpcre-native.do_configure"
"libpcre-native.do_populate_lic" -> "libpcre-native.do_patch"
"luneos-dev-emulator-appliance.do_rm_work_all" -> "libpcre-native.do_rm_work"
"libpcre-native.do_rm_work" -> "libpcre-native.do_build"
"glib-2.0-native.do_configure" -> "libpcre-native.do_populate_sysroot"
"libpcre-native.do_patch" -> "libpcre-native.do_unpack"
"luneos-dev-image.do_image" -> "libpcre-native.do_populate_lic"
"luneos-dev-image.do_build" -> "libpcre-native.do_build"
Comment 3 Ross Burton 2016-08-23 15:38:36 UTC
I've never seen this in master, have you?  Is this specific to the krogoth release?
Comment 4 Richard Purdie 2016-09-21 21:47:25 UTC
Is this regularly reproducing? We did recently hit a similar libpcre-native failure with rpm-native. This turned out to be a bitbake bug when there were problems with the sstate feed (rpm-native was valid and llibpcre-native wasn't).

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d3e6e1054c148983370febdab362628d9854bc24 was the fix.
Comment 5 Ross Burton 2016-09-28 16:34:46 UTC
We this this was resolved in the commit that Richard mentioned, so I'm marking this as resolved.

Martin, if you can still replicate with that fix applied, please re-open.