| Summary: | [Test Case 207] sudoku-savant project compile in sdk image | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Runtime] General Runtime | Reporter: | Chandrak <chandrak> | ||||
| Component: | General Runtime | Assignee: | Laurentiu Palcu <laurentiu.palcu> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | corneliux.stoicescu, jessica.zhang, raj.khem, richard.purdie, sgw, yi.zhao | ||||
| Version: | 1.5 | ||||||
| Target Milestone: | 1.5 M5 | ||||||
| Hardware: | x86 | ||||||
| OS: | arm | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Chandrak
2013-09-06 11:13:06 UTC
Apparently, the cause of this is this commit: 6ccd4d6a9d3910b6e729fe2d00056d8d325403c8 It's increasing the memory for qemu machines from 128 to 256M. This, in theory, should not lead to compilation issues inside qemu machine... I believe the problem is well hidden in qemu. I also tested the latest qemu HEAD and it's still reproducible. The only workaround, for now, is to run qemu with qemuparams="-m 128". In this case, the compilation will succeed. I'll continue to investigate this for a while. Hi Laurentiu, This issue also happens on qemumips and qemuppc with the same reason. I went further with my investigations and this is what I found out: * it happens with the 4.8.1 toolchain (4.7.2 works just fine); * I managed to find out that using the 4.7.2 toolchain but replacing just the cc1plus binary with the 4.8.1 one makes the problem appear; * it happens on the 256MB RAM beagleboard too (so I ruled out qemu); * it does not happen in ubuntu 13.04 running on the same beagleboard and using the 4.8.1 toolchain; * doing "ulimit -v 131072" before doing make, 'fixes' the problem; So, next, I'll try have a look in the ubuntu toolchain source package to see if there are any patches that we don't. I can also reproduce this on a kernel memory limited (using mem=256M) RaspberryPi I activated hard-float for beagleboard, since ubuntu's packages were compiled with hard-float, but it still reproduces... So soft-float/hard-float is ruled out. I also had a look into ubuntu's patches for gcc-4.8 but couldn't spot anything obvious in patch descriptions. However, there are 122 patches... I also tried to build gcc 4.8 out of Yocto tree, somehow, by generating an arm sato-sdk toolchain and have it build the gcc but, to this moment, I didn't succeed. This would help testing various versions of gcc without Yocto overhead and could be easily deployed on target. Created attachment 1553 [details]
configure command line differences
Apparently, the ubuntu patches, applied on top of ours don't make any difference. I also tried to remove the patches we added in 4.8, the same thing. I attached a file with the differences between the ubuntu configure command line and ours. I will try to activate/deactivate some of them to see if it will make any difference. https://bugzilla.yoctoproject.org/attachment.cgi?id=1553 I had a look at this. I ran a build with no ulimit which failed, then moved the source to a safe location and then did the same thing with a ulimit, letting it build up the point it failed. I then diffed the source, the interesting thing was board.rpo was different, specifically: root@qemuarm:~/sudoku-savant-1.3/src# diff -u board.rpo* --- board.rpo 2013-10-07 16:27:54.000000000 +0000 +++ board.rpo2 2013-10-07 16:19:37.000000000 +0000 @@ -1,6 +1,12 @@ M board.cpp D /home/root/sudoku-savant-1.3/src -A '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-D' 'PACKAGE_DATA_DIR="/usr/local/share"' '-D' 'PACKAGE_LOCALE_DIR="/usr/local/share/locale"' '-pthread' '-I' '/usr/include/gtk-2.0' '-I' '/usr/lib/gtk-2.0/include' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/atk-1.0' '-I' '/usr/include/cairo' '-I' '/usr/include/pixman-1' '-I' '/usr/include/libpng16' '-I' '/usr/include/gdk-pixbuf-2.0' '-I' '/usr/include/libpng16' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/harfbuzz' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/glib-2.0' '-I' '/usr/lib/glib-2.0/include' '-I' '/usr/include/freetype2' '-frepo' '-fno-implement-inlines' '-ansi' '-Wpedantic' '-pipe' '-Wall' '-Winline' '-Wshadow' '-Wsign-compare' '-Woverloaded-virtual' '-Wextra' '--param' 'max-inline-insns-single=400' '-g' '-O2' '-MT' 'board.o' '-MD' '-MP' '-MF' '.deps/board.Tpo' '-c' '-o' 'board.o' '-shared-libgcc' '-mfloat-abi=soft' '-mtls-dialect=gnu' '-frandom-seed=b3abe1519baebde9' +A '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-D' 'PACKAGE_DATA_DIR="/usr/local/share"' '-D' 'PACKAGE_LOCALE_DIR="/usr/local/share/locale"' '-pthread' '-I' '/usr/include/gtk-2.0' '-I' '/usr/lib/gtk-2.0/include' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/atk-1.0' '-I' '/usr/include/cairo' '-I' '/usr/include/pixman-1' '-I' '/usr/include/libpng16' '-I' '/usr/include/gdk-pixbuf-2.0' '-I' '/usr/include/libpng16' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/harfbuzz' '-I' '/usr/include/pango-1.0' '-I' '/usr/include/glib-2.0' '-I' '/usr/lib/glib-2.0/include' '-I' '/usr/include/freetype2' '-frepo' '-fno-implement-inlines' '-ansi' '-Wpedantic' '-pipe' '-Wall' '-Winline' '-Wshadow' '-Wsign-compare' '-Woverloaded-virtual' '-Wextra' '--param' 'max-inline-insns-single=400' '-g' '-O2' '-MT' 'board.o' '-MD' '-MP' '-MF' '.deps/board.Tpo' '-c' '-o' 'board.o' '-shared-libgcc' '-mfloat-abi=soft' '-mtls-dialect=gnu' '-frandom-seed=867bbe3ff9e0bf26' '-shared-libgcc' +O _ZNK6sudoku5Board4PushINS_6SquareEEclERS2_ +O _ZNK6sudoku5Board4PushINS_8SequenceEEclERS2_ +O _ZNK6sudoku9DropStackINS_8SequenceEEclERS1_ +O _ZNK6sudoku9DropStackINS_6SquareEEclERS1_ +O _ZNK6sudoku5ClearINS_8SequenceEEclERS1_ +O _ZNK6sudoku5ClearINS_6SquareEEclERS1_ O _ZTISt7collateIcE O _ZTISt7collateIwE O _ZTISt14collate_bynameIcE @@ -99,12 +105,12 @@ O _ZTVSt18basic_stringstreamIwSt11char_traitsIwESaIwEE O _ZTVN6sudoku6ActionINS_8SequenceEEE O _ZTVN6sudoku6ActionINS_6SquareEEE -O _ZTVN6sudoku5Board4PushINS_6SquareEEE -O _ZTVN6sudoku5Board4PushINS_8SequenceEEE -O _ZTVN6sudoku9DropStackINS_8SequenceEEE -O _ZTVN6sudoku9DropStackINS_6SquareEEE -O _ZTVN6sudoku5ClearINS_8SequenceEEE -O _ZTVN6sudoku5ClearINS_6SquareEEE +C _ZTVN6sudoku5Board4PushINS_6SquareEEE +C _ZTVN6sudoku5Board4PushINS_8SequenceEEE +C _ZTVN6sudoku9DropStackINS_8SequenceEEE +C _ZTVN6sudoku9DropStackINS_6SquareEEE +C _ZTVN6sudoku5ClearINS_8SequenceEEE +C _ZTVN6sudoku5ClearINS_6SquareEEE O _ZNK9__gnu_cxx17__normal_iteratorIPKPN6sudoku6SquareESt6vectorIS3_SaIS3_EEE4baseEv O _ZNK9__gnu_cxx13new_allocatorISt10_List_nodeIN6sudoku7BitmaskEEE8max_sizeEv O _ZNSt11__copy_moveILb0ELb1ESt26random_access_iterator_tagE8__copy_mIPN6sudoku6SquareEEEPT_PKS6_S9_S7_ @@ -368,7 +374,7 @@ O _ZNSt12_Vector_baseIN6sudoku8SequenceESaIS1_EE19_M_get_Tp_allocatorEv O _ZNSt12_Vector_baseIN6sudoku8SequenceESaIS1_EED1Ev O _ZNSt12_Vector_baseIN6sudoku8SequenceESaIS1_EED2Ev -O _ZNSt10_List_baseIN6sudoku6SquareESaIS1_EE8_M_clearEv +C _ZNSt10_List_baseIN6sudoku6SquareESaIS1_EE8_M_clearEv O _ZNSaISt10_List_nodeIN6sudoku6SquareEEED1Ev O _ZNSaISt10_List_nodeIN6sudoku6SquareEEED2Ev O _ZSt8distanceISt20_List_const_iteratorIN6sudoku6SquareEEENSt15iterator_traitsIT_E15difference_typeES5_S5_ @@ -378,7 +384,7 @@ O _ZNSt10_List_baseIN6sudoku6Square5StateESaIS2_EE8_M_clearEv O _ZSt8__fill_aIPmiEN9__gnu_cxx11__enable_ifIXsrSt11__is_scalarIT0_E7__valueEvE6__typeET_S8_RKS4_ O _ZSt12__niter_baseIPmENSt11_Niter_baseIT_E13iterator_typeES2_ -O _ZNSt4listIN6sudoku6SquareESaIS1_EE4sortINS0_5Board5ByTagEEEvT_ +C _ZNSt4listIN6sudoku6SquareESaIS1_EE4sortINS0_5Board5ByTagEEEvT_ O _ZSt8for_eachISt14_List_iteratorIN6sudoku6SquareEENS1_5Board6SetTagIS2_EEET0_T_S8_S7_ O _ZN6sudoku5Board6SetTagINS_6SquareEEC1EPj O _ZN6sudoku5Board6SetTagINS_6SquareEEC2EPj @@ -426,8 +432,8 @@ O _ZN6sudoku11do_for_eachIN9__gnu_cxx17__normal_iteratorIPNS_8SequenceESt6vectorIS3_SaIS3_EEEENS_6ActionIS3_EEEEvT_RKSB_RKT0_ O _ZNSt6vectorIN6sudoku8SequenceESaIS1_EE3endEv O _ZNSt6vectorIN6sudoku8SequenceESaIS1_EE5beginEv -O _ZNSt6vectorIN6sudoku8SequenceESaIS1_EED1Ev -O _ZNSt6vectorIN6sudoku8SequenceESaIS1_EED2Ev +C _ZNSt6vectorIN6sudoku8SequenceESaIS1_EED1Ev +C _ZNSt6vectorIN6sudoku8SequenceESaIS1_EED2Ev O _ZNSt10_List_baseIN6sudoku6SquareESaIS1_EED1Ev O _ZNSt10_List_baseIN6sudoku6SquareESaIS1_EED2Ev O _ZNKSt4listIN6sudoku6SquareESaIS1_EE4sizeEv which interestingly look like the symbols the linker is complaining about. I've confirmed that a "cd src; make board.o" with and without a ulimit result in different .rpo files. So we now have a simplified test case, and a better idea of exactly where the build diverges. Somehow, we trigger an issue in the generation of the .rpo file. so when you say ubuntu compiler works. Does it work on top of yocto ? or its a complete ubuntu systems. I ask because there could be more factors influencing then just gcc itself. (In reply to comment #9) > so when you say ubuntu compiler works. Does it work on top of yocto ? > or its a complete ubuntu systems. I ask because there could be more > factors influencing then just gcc itself. Complete ubuntu 13.04 running on beagleboard. (In reply to comment #10) > (In reply to comment #9) > > so when you say ubuntu compiler works. Does it work on top of yocto ? > > or its a complete ubuntu systems. I ask because there could be more > > factors influencing then just gcc itself. > > Complete ubuntu 13.04 running on beagleboard. OK. Then the issue could be elsewhere. Can you try this take 3.8 kernel from dylan branch and use that plus current root file system and see if you still can reproduce it. I think I have this pretty much figured out apart from a simpler reliable test case: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=18ef9fd54e97cce7975d91f6af73e65ea2c01b21 Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1960f0068410ca62b27887f5f2607a80dba596b9 This was not fixed in dora but is fixed in master. This is why I am marking this as VERIFIED and opening a new bug for 1.5.1 . Created bug 5398 to address this issue in 1.5.1 . |