[OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories

[Koen Kooi]

Op 1 jul 2011, om 10:10 heeft Richard Purdie het volgende geschreven:

> On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
>> Op 1 jul 2011, om 01:26 heeft Saul Wold het volgende geschreven:
>> 
>>> On 06/28/2011 02:05 AM, Robert Yang wrote:
>>>> Changes of V4:
>>>> 
>>>> * Change the definition of GLIBC_DYNAMIC_LINKER as Richard suggested.
>>>> 
>>>>  e.g., the entries in the files that look like:
>>>>  #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
>>>> 
>>>>  become
>>>> 
>>>>  #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
>>>> 
>>>>  and we define SYSTEMLIBS_DIR in defaults.h.
>>>> 
>>>>  NOTE, the round brackets:
>>>>  #define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR "/ld-linux-x86-64.so.2")
>>>> 
>>>>  doesn't work in in the following define:
>>>> 
>>>>  #define LINUX_DYNAMIC_LINKER \
>>>>          CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER)
>>>> 
>>>>  so use:
>>>>  #define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
>>>> 
>>>> * Compare to V3, reduce two patches which are for gcc-crosssdk.inc and
>>>>  gcc-cross-canadian which are not needed any more.
>>>> 
>>>> * Fix the conflicts(gcc-4.6.0 ->  gcc-4.6, and the ${BRANCH})
>>>> 
>>>> * Both tested 4.5.1 and 4.6:
>>>>  $ bitbake meta-toolchain core-image-sato
>>>>  $ runqemu qemurm
>>>> 
>>>>  Also unpack the sdk to /opt and test to make sure the toolchain works well.
>>>> 
>>>> 
>>>> The following changes since commit a1f79a7896b6411669b3ccada6204d2695e80fc5:
>>>> 
>>>>  runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100)
>>>> 
>>>> are available in the git repository at:
>>>>  git://git.pokylinux.org/poky-contrib robert/share_gcc
>>>>  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/share_gcc
>>>> 
>>>> Robert Yang (4):
>>>>  bitbake: share source directory
>>>>  Share gcc work directories
>>>>  gcc-4.5.1: share work directories
>>>>  gcc-4.6: share work directories
>>>> 
>>>> bitbake/lib/bb/build.py                            |    4 +-
>>>> bitbake/lib/bb/cache.py                            |    3 +
>>>> bitbake/lib/bb/runqueue.py                         |   10 +++
>>>> meta/recipes-devtools/gcc/gcc-4.5.1.inc            |    1 +
>>>> .../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch   |   57 ++++++++++++++
>>>> meta/recipes-devtools/gcc/gcc-4.6.inc              |    5 +-
>>>> .../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch |   80 ++++++++++++++++++++
>>>> meta/recipes-devtools/gcc/gcc-common.inc           |   32 +++++++-
>>>> meta/recipes-devtools/gcc/gcc-configure-common.inc |   48 +++++++-----
>>>> meta/recipes-devtools/gcc/gcc-configure-cross.inc  |    4 +-
>>>> meta/recipes-devtools/gcc/gcc-crosssdk.inc         |    6 --
>>>> 11 files changed, 218 insertions(+), 32 deletions(-)
>>>> create mode 100644 meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
>>>> create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core at lists.openembedded.org
>>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>> 
>>> 
>>> Merged into OE-Core
>> 
>> incremental build with rm_work turned on:
>> 
>> ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092 for further information)
>> ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
>> Log data follows:
>> | + cd /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
>> | + do_configure
>> | + sed -i '/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h' -e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
>> | sed: can't read /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h: No such file or directory
>> | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092 for further information)
>> NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure: Failed
>> ERROR: Task 764 (/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb, do_configure) failed with exit code '1'
>> 
>> Can this patchset get reverted please and reapplied when it actually has been tested to work?
> 
> Testing patches is not the sole responsibility of myself and Saul. This
> gcc patchset was on the mailing list for a considerable time and has
> been tested in a variety of ways. Various breakage was identified found
> and those breakages were fixed. The fact there looks to be some
> incremental build issue with rm_work is unfortunate and likely easy to
> fix so I think this request is a little out of proportion.
> 
> If someone had reported the problem before it merged it would have
> waited until it was fixed before merging.

"They will therefore merge and I'm happy with them but it will be a few
more days before that happens. "

I was under the impression that I still had a few more days to test them now that the eglibc problems have been solved. I don't think you can blame people for not testing gcc when eglibc was still blowing up in their faces.

> I find it ironic you're one of the people asking to turn the autobuilder
> red, make warnings fatal and break things for everyone as 'its the only
> way to get people to look at and fix them; but on the other hand you're
> unhappy if testing of patches doesn't happen on every single combination
> of usages and something does break :/.

I was actually planning to test them today, now that eglibc works again.