using sato-sdk images from nightly build 20110226-1: http://autobuilder.pokylinux.org/nightly/20110226-1/qemu/qemuppc/ run command "gcc -c test.c",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 <http://gcc.gnu.org/bugs.html> for instructions. -------------------------------- test.c file for reference : #include <stdio.h> int main() { printf("hello,world!\n"); return 0; }
Test env: Host: Ubuntu 10.10 X86_64 Kernel: 2.6.35-25-generic #44-Ubuntu SMP
Just built the qemuppc image for sato-sdk. and ran it under qemu. gcc compilation for the mentioned test program worked without any issues.
*** Bug 417 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** 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't reproduced it locally. I even tried to manually build ppc on autobuilder, but still couldn't reproduce it. However, autobuilder ppc images still have the issue *occassionally*, and with a "bad" 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.
(In reply to comment #4) > (In reply to comment #3) > > *** 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't reproduced it locally. > I even tried to manually build ppc on autobuilder, but still couldn't reproduce > it. > However, autobuilder ppc images still have the issue *occassionally*, and with > a "bad" 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. BTW: looks it's somehow related to ldconfig: After running ldconfig in target, I can't reproduce the issue any longer.
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?
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.
(In reply to comment #6) > Has this every happened on a disk image or just nfs? It happens on a disk image > Please try disk image instead of UNFS. > What about real HW? We haven't ppc HW to try on. > 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't reproduce the issue, either. We can't reproduce the issue locally. So looks prelink is not the cause.
This may be related to the UNFS issue (BUG 414).
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 "ldconfig" , the error not net again.
(In reply to comment #10) > 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 "ldconfig" , 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 ?= "image-mklibs image-prelink" Remove "image-prelink" from the above -- or simply set: USER_CLASSES = "image-mklibs"
(In reply to comment #11) > (In reply to comment #10) > > 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 "ldconfig" , 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 ?= "image-mklibs image-prelink" > > Remove "image-prelink" from the above -- or simply set: USER_CLASSES = > "image-mklibs" use the images which I build manually sometimes before, the error also met.
sorry, use the images which I build manually sometimes before, the error not met.
(In reply to comment #10) > 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 "ldconfig" , 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/
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 <stdio.h> int main() { printf("hi there\n"); 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
Is it correct to say the issue only happens when files are on NFS in the guest ?
(In reply to comment #15) > 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 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. > 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. 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 "echo -n | cpp -" 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's not likely qemu is buggy here) (In reply to comment #16) > Is it correct to say the issue only happens when files are on NFS in the guest > ? I don't think so, because booting from .ext3 image directly can also reproduce the issue.
(In reply to comment #17) I could reproduce the failure on this image: > 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't know yet. Nitin
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' 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
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
Whilst these differences shouldn't be there and that is something we need to fix, can you confirm it is those differences causing this bug?
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="powerpc" OS="linux-gnu" -CC="powerpc-poky-linux-gcc -mcpu=603e -mhard-float --sysroot=/srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/sysroots/qemuppc" +CC="ccache powerpc-poky-linux-gcc -mcpu=603e -mhard-float --sysroot=/disk0/pokybuild/build0/tmp/sysroots/qemuppc"
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?
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't reproduce with either image then we have a reproducibility problem but I'm not sure chasing those differences will resolve this particular problem?
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.
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.
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 -> libxcb-dri2.so.0.0.0
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
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
Found a culprit line: this is disabling package file list for libxcb-dev #FILES_${PN}-dev = "${libdir}/libxcb.* ${libdir}/pkgconfig/*.pc ${includedir}/xcb/*.h" Why is it commented out ? Git blame found this commit introducing that line. commit 3de4627417e62595ce4349cb3a13c9180f8e6bfd Author: Robert Bragg <bob@openedhand.com> 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's a big commit and it'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'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'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
Fixing dangling link to /usr/lib/libxcb-dri2.so.0.0.0 didn't fix the ld.so.cache. So looks like ldconfig is not working in cross fashion for ppc.
A work around can be avoiding ldconfig at the timeof do_rootfs for ppc.
upgrading ldconfig-native to 2.12.1 did not help. I think we need ldconfig-cross recipe.
Fix for this bug is ready now. Endian-ness aware data handling & target vars aware code is added to the ldconfig. commits for the fix are pushed to the yocto & OE-core mailing lists. Thanks, Nitin
This commit has gone in master for fixing this issue. http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3
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.
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.
(In reply to comment #33) > upgrading ldconfig-native to 2.12.1 did not help. I think we need > ldconfig-cross recipe. (In reply to comment #35) > This commit has gone in master for fixing this issue. > http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3 (In reply to comment #37) > This bug is resolved now. Glad to see the bug was fixed! BTW, Nitin, comment #33 said "upgrading ldconfig-native to 2.12.1 did not help", so I think it'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's not that straightforward to me so I'm curious. :-)
(In reply to comment #38) > (In reply to comment #33) > > upgrading ldconfig-native to 2.12.1 did not help. I think we need > > ldconfig-cross recipe. > (In reply to comment #35) > > This commit has gone in master for fixing this issue. > > http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f897723207b00b4c9dcdb43107891b7b82ce22f3 > (In reply to comment #37) > > This bug is resolved now. > Glad to see the bug was fixed! > BTW, Nitin, comment #33 said "upgrading ldconfig-native to 2.12.1 did not > help", so I think it'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's not that typo... I meant "without the patch". sorry. > straightforward to me so I'm curious. :-)
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't know why it did not fail always. Possibly there is some randomness in the ld.so to overcome cache issues. Nitin
(In reply to comment #40) > 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't know why it did not fail > always. Possibly there is some randomness in the ld.so to overcome cache > issues. > Nitin Nitin, I got it. Thank you very much for the fixing and the clarification! :-)
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
Bernard: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=9361df5ec235435f71774f3f93812f52af6f0a2e
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