<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>780</bug_id>
          
          <creation_ts>2011-02-27 23:25:08 +0000</creation_ts>
          <short_desc>gcc segfault on qemuppc (nightly build 20110226-1)</short_desc>
          <delta_ts>2011-05-16 03:59:10 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>devtools / tool chain</component>
          <version>1.0</version>
          <rep_platform>x86</rep_platform>
          <op_sys>ppc</op_sys>
          <bug_status>VERIFIED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>High</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>1.1</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="liang li">liang.li2</reporter>
          <assigned_to name="Nitin Kamble">nitin.a.kamble</assigned_to>
          <cc>dexuan.cui</cc>
    
    <cc>jessica.zhang</cc>
    
    <cc>jiajun.xu</cc>
    
    <cc>ke.yu</cc>
    
    <cc>liangliang.wang</cc>
    
    <cc>mark.hatle</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
    
    <cc>poky.bs.watcher</cc>
    
    <cc>poky.watcher</cc>
    
    <cc>richard.purdie</cc>
    
    <cc>sgw</cc>
    
    <cc>xianchao.zhang</cc>
    
    <cc>yi.zhao</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>---</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>12152</commentid>
    <comment_count>0</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-02-27 23:25:08 +0000</bug_when>
    <thetext>using sato-sdk images from nightly build 20110226-1:
http://autobuilder.pokylinux.org/nightly/20110226-1/qemu/qemuppc/
run command &quot;gcc -c test.c&quot;,error met below:

root@qemuppc:~# gcc -c test.c
In file included from /usr/include/libio.h:548:0,
                 from /usr/include/stdio.h:75,
                 from test1.c:1:
/usr/include/bits/libio-ldbl.h:24:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See &lt;http://gcc.gnu.org/bugs.html&gt; for instructions.

--------------------------------

test.c file for reference :
#include &lt;stdio.h&gt;
int main()
{
        printf(&quot;hello,world!\n&quot;);
        return 0;
}</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12153</commentid>
    <comment_count>1</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-02-27 23:29:19 +0000</bug_when>
    <thetext>Test env:
Host: Ubuntu 10.10 X86_64
Kernel: 2.6.35-25-generic #44-Ubuntu SMP</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12170</commentid>
    <comment_count>2</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-02-28 15:39:50 +0000</bug_when>
    <thetext>Just built the qemuppc image for sato-sdk. and ran it under qemu. gcc compilation for the mentioned test program worked without any issues.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12180</commentid>
    <comment_count>3</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-02-28 22:32:49 +0000</bug_when>
    <thetext>*** Bug 417 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12181</commentid>
    <comment_count>4</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-02-28 22:34:58 +0000</bug_when>
    <thetext>(In reply to comment #3)
&gt; *** Bug 417 has been marked as a duplicate of this bug. ***

Looks we do have a rather tricky and hard-to-reproduce bug on ppc here..
Till now, I haven&apos;t reproduced it locally.
I even tried to manually build ppc on autobuilder, but still couldn&apos;t reproduce
it.
However, autobuilder ppc images still have the issue *occassionally*, and with
a &quot;bad&quot; image, I estimiate we have a 30%~50% probability to reproduce the
issue.

So at present I think we might as well reopen the bug to track the issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12184</commentid>
    <comment_count>5</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-02-28 23:26:38 +0000</bug_when>
    <thetext>(In reply to comment #4)
&gt; (In reply to comment #3)
&gt; &gt; *** Bug 417 has been marked as a duplicate of this bug. ***
&gt; Looks we do have a rather tricky and hard-to-reproduce bug on ppc here..
&gt; Till now, I haven&apos;t reproduced it locally.
&gt; I even tried to manually build ppc on autobuilder, but still couldn&apos;t reproduce
&gt; it.
&gt; However, autobuilder ppc images still have the issue *occassionally*, and with
&gt; a &quot;bad&quot; image, I estimiate we have a 30%~50% probability to reproduce the
&gt; issue.
&gt; So at present I think we might as well reopen the bug to track the issue.

BTW: looks it&apos;s somehow related to ldconfig:
After running ldconfig in target, I can&apos;t reproduce the issue any longer.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12370</commentid>
    <comment_count>6</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2011-03-08 13:39:16 +0000</bug_when>
    <thetext>Has this every happened on a disk image or just nfs?
Please try disk image instead of UNFS.

What about real HW?

What about disabling prelink?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12393</commentid>
    <comment_count>7</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-03-08 20:17:44 +0000</bug_when>
    <thetext>In the new two nightly build of qemuppc( 20110301-4 and 20110305-4), the error not found using disk images (not UNFS).
And the error not met when using mpc8315e-rdb sato-sdk disk images in newly nightly build of 20110301-4 and 20110305-4.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12402</commentid>
    <comment_count>8</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-03-09 03:26:53 +0000</bug_when>
    <thetext>(In reply to comment #6)
&gt; Has this every happened on a disk image or just nfs?
It happens on a disk image
&gt; Please try disk image instead of UNFS.
&gt; What about real HW?
We haven&apos;t ppc HW to try on.
&gt; What about disabling prelink?
The strange issue is we can only occassionally see the bug on autobuilder nightly builds, but manually building ppc on autobuilder can&apos;t reproduce the issue, either.
We can&apos;t reproduce the issue locally.
So looks prelink is not the cause.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12578</commentid>
    <comment_count>9</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2011-03-14 16:35:03 +0000</bug_when>
    <thetext>This may be related to the UNFS issue (BUG 414).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12616</commentid>
    <comment_count>10</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-03-15 04:18:25 +0000</bug_when>
    <thetext>also happend on sato-sdk images of nightly build 20110313-2:
http://autobuilder.pokylinux.org/nightly/20110313-2/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110314080355.rootfs.ext3
after run &quot;ldconfig&quot; , the error not net again.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12633</commentid>
    <comment_count>11</comment_count>
    <who name="Mark Hatle">mark.hatle</who>
    <bug_when>2011-03-15 09:00:40 +0000</bug_when>
    <thetext>(In reply to comment #10)
&gt; also happend on sato-sdk images of nightly build 20110313-2:
&gt; http://autobuilder.pokylinux.org/nightly/20110313-2/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110314080355.rootfs.ext3
&gt; after run &quot;ldconfig&quot; , the error not net again.

We need to try some additional steps to identify the issue.

Can you attempt to build the rootfs, instead of downloading the pre-built version?  If this exhibits the same failure (without running ldconfig) then we have the ability to try a few things.

One theory is that something is going wrong with the prelinking of the system.  There is a potential with the prelinker and non pic compiled binaries of strange failure cases similar to this.

If you can build and reproduce the problem, then you can disable prelinking by modifying the conf/local.conf file.  Specifically:

USER_CLASSES ?= &quot;image-mklibs image-prelink&quot;

Remove &quot;image-prelink&quot; from the above -- or simply set: USER_CLASSES = &quot;image-mklibs&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12672</commentid>
    <comment_count>12</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-03-15 21:55:25 +0000</bug_when>
    <thetext>(In reply to comment #11)
&gt; (In reply to comment #10)
&gt; &gt; also happend on sato-sdk images of nightly build 20110313-2:
&gt; &gt; http://autobuilder.pokylinux.org/nightly/20110313-2/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110314080355.rootfs.ext3
&gt; &gt; after run &quot;ldconfig&quot; , the error not net again.
&gt; 
&gt; We need to try some additional steps to identify the issue.
&gt; 
&gt; Can you attempt to build the rootfs, instead of downloading the pre-built
&gt; version?  If this exhibits the same failure (without running ldconfig) then we
&gt; have the ability to try a few things.
&gt; 
&gt; One theory is that something is going wrong with the prelinking of the system. 
&gt; There is a potential with the prelinker and non pic compiled binaries of
&gt; strange failure cases similar to this.
&gt; 
&gt; If you can build and reproduce the problem, then you can disable prelinking by
&gt; modifying the conf/local.conf file.  Specifically:
&gt; 
&gt; USER_CLASSES ?= &quot;image-mklibs image-prelink&quot;
&gt; 
&gt; Remove &quot;image-prelink&quot; from the above -- or simply set: USER_CLASSES =
&gt; &quot;image-mklibs&quot;

use the images which I build manually sometimes before, the error also met.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12673</commentid>
    <comment_count>13</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-03-15 22:08:41 +0000</bug_when>
    <thetext>sorry, use the images which I build manually sometimes before, the error not met.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12893</commentid>
    <comment_count>14</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-03-21 22:59:09 +0000</bug_when>
    <thetext>(In reply to comment #10)
&gt; also happend on sato-sdk images of nightly build 20110313-2:
&gt; http://autobuilder.pokylinux.org/nightly/20110313-2/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110314080355.rootfs.ext3
&gt; after run &quot;ldconfig&quot; , the error not net again.

also happened on sato-sdk images of nightly build 20110318-3:
http://autobuilder.pokylinux.org/nightly/20110318-3/machines/qemu/qemuppc/</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12935</commentid>
    <comment_count>15</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-23 09:04:12 +0000</bug_when>
    <thetext>I tried reproducing the issue with the lsb-sdk image from here :http://autobuilder.pokylinux.org/nightly/20110318-3/machines/qemu/qemuppc/
But I did not get the issue. I did not change anything in the image, just downloaded image, booted it and then typed the above mentioned program in the t.c file and build it using gcc t.c command.

If I am not able to reproduce the issue with the same image, then the differences may be in qemu. Possibly qemu is making some mistake while emulating some ppc code.


root@qemuppc:~# cat t.c
#include &lt;stdio.h&gt;

int main()
{
  printf(&quot;hi there\n&quot;);
  return 0;
}

root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c
root@qemuppc:~# gcc t.c

root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c
root@qemuppc:~# gcc -c t.c</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12969</commentid>
    <comment_count>16</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-24 10:47:24 +0000</bug_when>
    <thetext>Is it correct to say the issue only happens when files are on NFS in the guest ?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12978</commentid>
    <comment_count>17</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-03-25 01:57:25 +0000</bug_when>
    <thetext>(In reply to comment #15)
&gt; I tried reproducing the issue with the lsb-sdk image from here
&gt; :http://autobuilder.pokylinux.org/nightly/20110318-3/machines/qemu/qemuppc/
&gt; But I did not get the issue. I did not change anything in the image, just
Please try the sato-sdk image:
http://autobuilder.pokylinux.org/nightly/20110318-3/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110319101530.rootfs.ext3 that does have the bug in my side.

&gt; downloaded image, booted it and then typed the above mentioned program in the
&gt; t.c file and build it using gcc t.c command.
&gt; If I am not able to reproduce the issue with the same image, then the
&gt; differences may be in qemu. Possibly qemu is making some mistake while
&gt; emulating some ppc code.
If you can also reproduce this bug with the above sato-sdk image I mentioned, qemu may be ok.
A more easy way to reproduce the issue with the image:
run &quot;echo -n | cpp -&quot; in the ppc target for several times and we can see the bug.
Also looks running ldconfig in the target can work around the bug (so looks it&apos;s not likely qemu is buggy here)

(In reply to comment #16)
&gt; Is it correct to say the issue only happens when files are on NFS in the guest
&gt; ?
I don&apos;t think so, because booting from .ext3 image directly can also reproduce the issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12988</commentid>
    <comment_count>18</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-25 09:22:38 +0000</bug_when>
    <thetext>(In reply to comment #17)
I could reproduce the failure on this image:
&gt; http://autobuilder.pokylinux.org/nightly/20110318-3/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110319101530.rootfs.ext3

It fails/succeeds randomly. Looks like some kind of race condition to me. where, don&apos;t know yet.

Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12991</commentid>
    <comment_count>19</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-25 14:54:25 +0000</bug_when>
    <thetext>As per my understanding the failure does not happen for every image generated by autobuilder. So possibly something occasionally goes wrong while generating an image on autobuilder. I am trying to build an image with same commit as the failing image&apos; sources. And see if I can reproduce the issue with locally built image, and if not then check the differences in the two images.

If any of my assumptions are wrong, please let me know.

Thanks,
Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>12996</commentid>
    <comment_count>20</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-26 08:17:49 +0000</bug_when>
    <thetext>I diffed list of files present in the autobuilder built sato sdk ext3 image vs locally built sato sdk ext3 image for the same checked out commit. And I am seeing these differences:

AFAICS these differences should not be there, irrespective of where is it built.
Is there any explanation for these differences? If not then possibly there is some bug somewhere which is causing some randomness in the image build process.

Thanks,
Nitin

--- autobuilder.list	2011-03-26 01:42:56.522031586 -0700
+++ localbuild.list	2011-03-25 13:18:49.245030918 -0700
@@ -291,7 +291,6 @@
 ./etc/gconf/schemas/gthumb-comments.schemas
 ./etc/gconf/schemas/gthumb_convert_format.schemas
 ./etc/gconf/schemas/gthumb_crop_options.schemas
-./etc/gconf/schemas/gthumb-gstreamer.schemas
 ./etc/gconf/schemas/gthumb_image_print.schemas
 ./etc/gconf/schemas/gthumb-image-viewer.schemas
 ./etc/gconf/schemas/gthumb-importer.schemas
@@ -475,6 +474,9 @@
 ./etc/rc6.d/S32portmap
 ./etc/rc6.d/S40umountfs
 ./etc/rc6.d/S90reboot
+./etc/rc.d
+./etc/rc.d/init.d
+./etc/rc.d/init.d/messagebus
 ./etc/rcS.d
 ./etc/rcS.d/S00psplash.sh
 ./etc/rcS.d/S02banner.sh
@@ -823,12 +825,20 @@
 ./lib/modules/2.6.37.3-yocto-standard+/kernel/net/netfilter/x_tables.ko
 ./lib/modules/2.6.37.3-yocto-standard+/modules.alias
 ./lib/modules/2.6.37.3-yocto-standard+/modules.alias.bin
+./lib/modules/2.6.37.3-yocto-standard+/modules.ccwmap
 ./lib/modules/2.6.37.3-yocto-standard+/modules.dep
 ./lib/modules/2.6.37.3-yocto-standard+/modules.dep.bin
 ./lib/modules/2.6.37.3-yocto-standard+/modules.devname
+./lib/modules/2.6.37.3-yocto-standard+/modules.ieee1394map
+./lib/modules/2.6.37.3-yocto-standard+/modules.inputmap
+./lib/modules/2.6.37.3-yocto-standard+/modules.isapnpmap
+./lib/modules/2.6.37.3-yocto-standard+/modules.ofmap
+./lib/modules/2.6.37.3-yocto-standard+/modules.pcimap
+./lib/modules/2.6.37.3-yocto-standard+/modules.seriomap
 ./lib/modules/2.6.37.3-yocto-standard+/modules.softdep
 ./lib/modules/2.6.37.3-yocto-standard+/modules.symbols
 ./lib/modules/2.6.37.3-yocto-standard+/modules.symbols.bin
+./lib/modules/2.6.37.3-yocto-standard+/modules.usbmap
 ./lib/security
 ./lib/security/pam_access.la
 ./lib/security/pam_debug.la
@@ -6250,14 +6260,18 @@
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/limits.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/linux
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/linux/a.out.h
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/nss3
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/nss3/secport.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/openssl
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/openssl/bn.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/README
-./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/ssl
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/slang
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/slang/slang.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/syslimits.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/X11
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/X11/Xw32defs.h
-./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/zutil.h
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/xulrunner-sdk-1.9.2
+./usr/lib/gcc/powerpc-poky-linux/4.5.1/include-fixed/xulrunner-sdk-1.9.2/std_semaphore.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include/float.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include/iso646.h
 ./usr/lib/gcc/powerpc-poky-linux/4.5.1/include/paired.h
@@ -6620,8 +6634,6 @@
 ./usr/lib/gthumb/extensions/.debug/libfile_manager.so
 ./usr/lib/gthumb/extensions/.debug/libfile_tools.so
 ./usr/lib/gthumb/extensions/.debug/libfile_viewer.so
-./usr/lib/gthumb/extensions/.debug/libgstreamer_tools.so
-./usr/lib/gthumb/extensions/.debug/libgstreamer_utils.so
 ./usr/lib/gthumb/extensions/.debug/libimage_print.so
 ./usr/lib/gthumb/extensions/.debug/libimage_rotation.so
 ./usr/lib/gthumb/extensions/.debug/libimage_viewer.so
@@ -6643,8 +6655,6 @@
 ./usr/lib/gthumb/extensions/file_manager.extension
 ./usr/lib/gthumb/extensions/file_tools.extension
 ./usr/lib/gthumb/extensions/file_viewer.extension
-./usr/lib/gthumb/extensions/gstreamer_tools.extension
-./usr/lib/gthumb/extensions/gstreamer_utils.extension
 ./usr/lib/gthumb/extensions/image_print.extension
 ./usr/lib/gthumb/extensions/image_rotation.extension
 ./usr/lib/gthumb/extensions/image_viewer.extension
@@ -6683,12 +6693,6 @@
 ./usr/lib/gthumb/extensions/libfile_viewer.a
 ./usr/lib/gthumb/extensions/libfile_viewer.la
 ./usr/lib/gthumb/extensions/libfile_viewer.so
-./usr/lib/gthumb/extensions/libgstreamer_tools.a
-./usr/lib/gthumb/extensions/libgstreamer_tools.la
-./usr/lib/gthumb/extensions/libgstreamer_tools.so
-./usr/lib/gthumb/extensions/libgstreamer_utils.a
-./usr/lib/gthumb/extensions/libgstreamer_utils.la
-./usr/lib/gthumb/extensions/libgstreamer_utils.so
 ./usr/lib/gthumb/extensions/libimage_print.a
 ./usr/lib/gthumb/extensions/libimage_print.la
 ./usr/lib/gthumb/extensions/libimage_print.so
@@ -7241,6 +7245,8 @@
 ./usr/lib/libgtk-x11-2.0.so
 ./usr/lib/libgtk-x11-2.0.so.0
 ./usr/lib/libgtk-x11-2.0.so.0.2200.1
+./usr/lib/libhal.so.1
+./usr/lib/libhal.so.1.0.0
 ./usr/lib/libhistory.a
 ./usr/lib/libhistory.so
 ./usr/lib/libhistory.so.6
@@ -12142,7 +12148,6 @@
 ./usr/share/gthumb/ui/image-viewer-preferences.ui
 ./usr/share/gthumb/ui/import-preferences.ui
 ./usr/share/gthumb/ui/jpeg-options.ui
-./usr/share/gthumb/ui/mediabar.ui
 ./usr/share/gthumb/ui/organize-files-task.ui
 ./usr/share/gthumb/ui/organize-files.ui
 ./usr/share/gthumb/ui/overwrite-dialog.ui
@@ -12158,7 +12163,6 @@
 ./usr/share/gthumb/ui/resize-images.ui
 ./usr/share/gthumb/ui/resize-options.ui
 ./usr/share/gthumb/ui/save-options-preferences.ui
-./usr/share/gthumb/ui/save-screenshot.ui
 ./usr/share/gthumb/ui/script-editor.ui
 ./usr/share/gthumb/ui/search-editor.ui
 ./usr/share/gthumb/ui/slideshow-preferences.ui
@@ -14708,7 +14712,6 @@
 ./usr/share/quilt/applied
 ./usr/share/quilt/compat
 ./usr/share/quilt/compat/awk
-./usr/share/quilt/compat/sendmail
 ./usr/share/quilt/delete
 ./usr/share/quilt/diff
 ./usr/share/quilt/edit
@@ -18489,6 +18492,8 @@
 ./var
 ./var/backups
 ./var/cache
+./var/db
+./var/db/sudo
 ./var/lib
 ./var/lib/bluetooth
 ./var/lib/misc
@@ -18750,7 +18755,6 @@
 ./var/lib/rpm/Sourcepkgid
 ./var/lib/rpm/Triggername
 ./var/lib/rpm/Version
-./var/lib/sudo
 ./var/local
 ./var/lock
 ./var/log</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13014</commentid>
    <comment_count>21</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2011-03-28 08:35:25 +0000</bug_when>
    <thetext>Whilst these differences shouldn&apos;t be there and that is something we need to fix, can you confirm it is those differences causing this bug?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13015</commentid>
    <comment_count>22</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-28 09:09:47 +0000</bug_when>
    <thetext>Also find that the autobuilder image did not use ccache while compiling:

diff -ru autobuilder/bin/bashbug localbuild/bin/bashbug
--- autobuilder/bin/bashbug      2011-03-19 04:34:45.000000000 -0700
+++ localbuild/bin/bashbug      2011-03-25 09:56:17.000000000 -0700
@@ -28,7 +28,7 @@
 #
 MACHINE=&quot;powerpc&quot;
 OS=&quot;linux-gnu&quot;
-CC=&quot;powerpc-poky-linux-gcc -mcpu=603e  -mhard-float --sysroot=/srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/sysroots/qemuppc&quot;
+CC=&quot;ccache powerpc-poky-linux-gcc -mcpu=603e  -mhard-float --sysroot=/disk0/pokybuild/build0/tmp/sysroots/qemuppc&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13031</commentid>
    <comment_count>23</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 08:41:42 +0000</bug_when>
    <thetext>I created another image from scratch, to see if it has any changes wrt the other locally built image. The list of files are exactly same. That shows that our build process is consistent and reproducible. Next target to look at is autobuilder build environment.
  Has this issue ever observed in non-autobuilder generated images?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13032</commentid>
    <comment_count>24</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2011-03-29 09:16:38 +0000</bug_when>
    <thetext>I suspect on the autobuilder, the act of bitbake XXX before this image has the effect of introducing the other dependencies. Are you saying if you download the autobuilder image, you see the segfault, if you use a locally built one you see the problem?

If so, surely copying sections of the broken image to the good one should highlight where the problem is?

If you can&apos;t reproduce with either image then we have a reproducibility problem but I&apos;m not sure chasing those differences will resolve this particular problem?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13033</commentid>
    <comment_count>25</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 09:27:06 +0000</bug_when>
    <thetext>RP,
 I could not reproduce this problem with the image I build locally. Also looking at comments on this bugzilla, nobody could reproduce the issue with locally generated images. In my case the issue can happen only autobuilder generated images. Also with autobuilder generated images, the issue is not consistently reproducible. On the same image if you run the command 10 times it may fail 5 times and succeed 5 times.
 
  Also running ldconfig inside the image seems like fixing the problem.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13035</commentid>
    <comment_count>26</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 16:23:28 +0000</bug_when>
    <thetext>there is some problem with the ldconfig cache in the failing case:

ls -l /etc/ld.so.cache
-rw-r--r--. 1 root root 48 Mar 19 05:39 ld.so.cache

And after running ldconfig manually in the image

ls -l  /etc/ld.so.cache
-rw-r--r--. 1 root root 43259 Mar 19 05:57 ld.so.cache

For the image ldconfig is run as part of do_rootfs function:
      # Run ldconfig on the image to create a valid cache
      # (new format for cross arch compatibility)
      ldconfig -r /disk0/pokybuild/build0/tmp/work/qemuppc-poky-linux/poky-image-sato-sdk-1.0-r0/rootfs -c new


It did not work well for the failing image.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13036</commentid>
    <comment_count>27</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 16:54:51 +0000</bug_when>
    <thetext>Tried running ldocnfig by hand through devshell of the poky-image-sato-sdk recipe:

Found a broken link for libxcb-dri2 library, which is breaking the ldconfig run.

$ ldconfig -r /disk0/pokybuild/build0/tmp/work/qemuppc-poky-linux/poky-image-sato-sdk-1.0-r0/rootfs -c new -v
/lib:
/usr/lib:
ldconfig: Cannot stat /usr/lib/libxcb-dri2.so: No such file or directory


and on the image:
# ls -l  /usr/lib/libxcb-dri2.so*
lrwxrwxrwx 1 root root 20 Mar 19 12:38 /usr/lib/libxcb-dri2.so -&gt; libxcb-dri2.so.0.0.0</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13037</commentid>
    <comment_count>28</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 17:05:00 +0000</bug_when>
    <thetext>And looking ad libxcb2 recipe work area:
The libxcb-dri2.so.0.0.0 file is not packaged in the libxcb-dev subpackage.


[nitin@nbuild1 packages-split]$ find . | grep dri2
./libxcb-dbg/usr/src/debug/libxcb-1.7-r0/libxcb-1.7/src/dri2.c
./libxcb-dbg/usr/src/debug/libxcb-1.7-r0/libxcb-1.7/src/dri2.h
./libxcb-dbg/usr/lib/.debug/libxcb-dri2.so.0
./libxcb-dbg/usr/lib/.debug/libxcb-dri2.so.0.0.0
./libxcb-dbg/usr/lib/.debug/libxcb-dri2.so
./libxcb-dev/usr/lib/pkgconfig/xcb-dri2.pc
./libxcb-dev/usr/lib/libxcb-dri2.a
./libxcb-dev/usr/lib/libxcb-dri2.so
./libxcb-dev/usr/lib/libxcb-dri2.la
./libxcb-dev/usr/include/xcb/dri2.h</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13038</commentid>
    <comment_count>29</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 17:07:20 +0000</bug_when>
    <thetext>log.do_package: also has lines warning this issue:
NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libxcb-dri2.so.0
NOTE:   /usr/lib/libxcb-dri2.so.0.0.0
NOTE: libxcb-dev contains dangling symlink to /usr/lib/libxcb-dri2.so.0.0.0</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13039</commentid>
    <comment_count>30</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 17:13:04 +0000</bug_when>
    <thetext>Found a culprit line: this is disabling package file list for libxcb-dev

#FILES_${PN}-dev = &quot;${libdir}/libxcb.* ${libdir}/pkgconfig/*.pc ${includedir}/xcb/*.h&quot;


Why is it commented out ? 
Git blame found this commit introducing that line.

commit 3de4627417e62595ce4349cb3a13c9180f8e6bfd
Author: Robert Bragg &lt;bob@openedhand.com&gt;
Date:   Mon Sep 22 13:33:19 2008 +0000

    Adds recipes to support building X servers based on the xfree86 DDX instead
    of kdrive and building mesa. It&apos;s a big commit and it&apos;s still rather rough
    around the edges, but there is a desire to get this in early so people can
    review the work and help polish the changes.
    
    Some of the notable bits:
    \u2022 DRI support in mesa and the X server. (configured in machine conf via
      MACHINE_DRI_MODULES variable)
    \u2022 XCB backend for xlib
    \u2022 A fairly lite X server build with lots of legacy modules disabled.
    
    I&apos;m sure there is plenty of other fairly low hanging fruit if we want to
    put more effort into reducing the size of the xserver build. Currently the
    server build comes in @ ~2.3MB vs a kdrive fbdev server build @ ~1MB. E.g
    xaa could be made conditional to save ~320K. Of course the kdrive server
    doesn&apos;t include glx stuff, which is a pretty big chunk.
    
    Also thanks to hrw, since I nabbed a some patches from him for this, and RP,
    for various bits of Poky style advice.
    
    
    git-svn-id: https://svn.o-hand.com/repos/poky/trunk@5205 311d38ba-8fff-0310-9ca6-ca027cbcb966</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13040</commentid>
    <comment_count>31</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 18:05:44 +0000</bug_when>
    <thetext>Fixing dangling link to /usr/lib/libxcb-dri2.so.0.0.0 didn&apos;t fix the ld.so.cache. So looks like ldconfig is not working in cross fashion for ppc.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13041</commentid>
    <comment_count>32</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-29 18:10:13 +0000</bug_when>
    <thetext>A work around can be avoiding ldconfig at the timeof do_rootfs for ppc.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13058</commentid>
    <comment_count>33</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-03-30 14:10:48 +0000</bug_when>
    <thetext>upgrading ldconfig-native to 2.12.1 did not help. I think we need ldconfig-cross recipe.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13119</commentid>
    <comment_count>34</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-04-04 12:28:37 +0000</bug_when>
    <thetext>Fix for this bug is ready now. Endian-ness aware data handling &amp; target vars aware code is added to the ldconfig. commits for the fix are pushed to the yocto &amp; OE-core mailing lists.

Thanks,
Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13144</commentid>
    <comment_count>35</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-04-06 17:00:40 +0000</bug_when>
    <thetext>This commit has gone in master for fixing this issue.

http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13265</commentid>
    <comment_count>36</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-04-14 02:31:01 +0000</bug_when>
    <thetext>The error not met on nightly build images 20110412-1:
http://autobuilder.pokylinux.org/nightly/20110412-1/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110413073453.rootfs.ext3
git info :
6bf6aec120744211fbabf2b4a167bfd1ab5866fd

If this bug is solved,then pls set the status of the bug to resolved ,then I will modified status to fixed,thanks.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13274</commentid>
    <comment_count>37</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-04-14 10:56:52 +0000</bug_when>
    <thetext>This bug is resolved now. While digging for this bug we exposed that a variation exists in file systems generated from the same commit. And Richard proposes to open another bug for that issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13285</commentid>
    <comment_count>38</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-04-14 18:09:28 +0000</bug_when>
    <thetext>(In reply to comment #33)
&gt; upgrading ldconfig-native to 2.12.1 did not help. I think we need
&gt; ldconfig-cross recipe.
(In reply to comment #35)
&gt; This commit has gone in master for fixing this issue.
&gt; http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3
(In reply to comment #37)
&gt; This bug is resolved now. 
Glad to see the bug was fixed!
BTW, Nitin, comment #33 said &quot;upgrading ldconfig-native to 2.12.1 did not help&quot;, so I think it&apos;s the patch endian-ness_handling.patch that fixed the bug? If so, could you please explain a bit about the randomicity of the bug without the bug? (i.e., gcc fails/succeeds randomly) Looks it&apos;s not that straightforward to me so I&apos;m curious. :-)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13286</commentid>
    <comment_count>39</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-04-14 18:10:55 +0000</bug_when>
    <thetext>(In reply to comment #38)
&gt; (In reply to comment #33)
&gt; &gt; upgrading ldconfig-native to 2.12.1 did not help. I think we need
&gt; &gt; ldconfig-cross recipe.
&gt; (In reply to comment #35)
&gt; &gt; This commit has gone in master for fixing this issue.
&gt; &gt; http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3
&gt; (In reply to comment #37)
&gt; &gt; This bug is resolved now. 
&gt; Glad to see the bug was fixed!
&gt; BTW, Nitin, comment #33 said &quot;upgrading ldconfig-native to 2.12.1 did not
&gt; help&quot;, so I think it&apos;s the patch endian-ness_handling.patch that fixed the bug?
&gt; If so, could you please explain a bit about the randomicity of the bug without
&gt; the bug? (i.e., gcc fails/succeeds randomly) Looks it&apos;s not that
typo... I meant &quot;without the patch&quot;. sorry.
&gt; straightforward to me so I&apos;m curious. :-)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13287</commentid>
    <comment_count>40</comment_count>
    <who name="Nitin Kamble">nitin.a.kamble</who>
    <bug_when>2011-04-14 18:14:11 +0000</bug_when>
    <thetext>Dexuan,
  What i found was, previously the ld.so.cache was incomplete/broken. And that caused the ld.so to fail intermittently. I still don&apos;t know why it did not fail always. Possibly there is some randomness in the ld.so to overcome cache issues.

Nitin</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13288</commentid>
    <comment_count>41</comment_count>
    <who name="Dexuan Cui">dexuan.cui</who>
    <bug_when>2011-04-14 18:23:10 +0000</bug_when>
    <thetext>(In reply to comment #40)
&gt; Dexuan,
&gt;   What i found was, previously the ld.so.cache was incomplete/broken. And that
&gt; caused the ld.so to fail intermittently. I still don&apos;t know why it did not fail
&gt; always. Possibly there is some randomness in the ld.so to overcome cache
&gt; issues.
&gt; Nitin
Nitin,
I got it.
Thank you very much for the fixing and the clarification! :-)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13289</commentid>
    <comment_count>42</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-04-14 18:32:10 +0000</bug_when>
    <thetext>verified on sato-sdk image in nightly build images 20110412-1:
http://autobuilder.pokylinux.org/nightly/20110412-1/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110413073453.rootfs.ext3
git info :
6bf6aec120744211fbabf2b4a167bfd1ab5866fd</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13804</commentid>
    <comment_count>43</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2011-05-13 10:57:12 +0000</bug_when>
    <thetext>Bernard:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9361df5ec235435f71774f3f93812f52af6f0a2e</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>13841</commentid>
    <comment_count>44</comment_count>
    <who name="liang li">liang.li2</who>
    <bug_when>2011-05-16 03:59:10 +0000</bug_when>
    <thetext>verified on sato-sdk image in 1.0.1 nightly build images 20110513-1:
http://autobuilder.pokylinux.org/nightly/20110513-1/machines/qemu/qemuppc/poky-image-sato-sdk-qemuppc-20110514074939.rootfs.ext3
git info:
1b159ff35d9f484e72afb8b19a9e69a2770d8379
branch:bernard</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>