**** BEGIN LOGGING AT Sat Dec 22 03:00:03 2018 Dec 22 08:41:08 khem: ouch! :) Dec 22 08:51:41 RP: khem: I am following about a share gcc-cross Dec 22 08:52:03 I have this strange test-case where -musl fails Dec 22 08:52:57 there is smthg different during gcc-cross configure that I am trying to find Dec 22 09:03:43 ant_home: which arch/machine and how does it fail? Dec 22 09:22:44 khem: I think we just do what I mentioned, make this conditional on TCLIBC Dec 22 09:23:04 khem: looking at gcc configure I had missed a section of this the first time I read it Dec 22 10:06:46 RP, it's a corner-case of mipsel/3.13.5 Dec 22 10:49:39 RP: with musl tc I get several "expr: syntax error" in do_configure and do_compile Dec 22 10:49:46 the build breaks Dec 22 10:50:23 userland compiles fine so I suspect something in the kernel classes Dec 22 12:38:52 ant_home: you mean on target gcc? Dec 22 16:37:45 ant_home: share full logs for kernel Dec 22 16:40:35 RP: we probably need to separate gcc for libcs Dec 22 16:42:09 community seems to be headed in another direction where they are knowing more and more about glibc features for target **** ENDING LOGGING AT Sat Dec 22 18:13:37 2018 **** BEGIN LOGGING AT Sat Dec 22 18:17:07 2018 Dec 22 18:17:16 khem: agreed. I updated -next Dec 22 18:20:07 RP: I dont see any regressions on meta-oe so I think we are almost good Dec 22 18:20:14 buildwise Dec 22 18:22:53 RP: http://errors.yoctoproject.org/Errors/Build/74120/ all failures are either gcc9 or known Dec 22 18:23:15 this is qemuppc http://errors.yoctoproject.org/Errors/Build/74125/ Dec 22 18:23:18 a bit more Dec 22 18:25:46 RP: send a musl upgrade patch, needed now that we have kernel 4.19 Dec 22 18:27:49 RP: and another one to get glibc happy with gold linker Dec 22 18:51:07 khem: ok, cool. I'll try and get this staged in -next. I'm a little nervous of merging the toolchain changes during the holidays, not sure if I should wait for a few weeks :/ Dec 22 18:51:33 on the contrary I think its best time Dec 22 18:51:50 we can fix the fallouts Dec 22 18:51:57 without much hue and cry:) Dec 22 18:53:02 or take advantage of humankind's short memory of 8seconds ... where people will come fresh after holiday and resume life assuming this is the current state of life there was no better Dec 22 20:39:43 RP: typo fixed here http://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=f119d5c16091cb9853c675fb5943ee1e12e8cf05 Dec 22 20:39:55 master-next wont go too far without this Dec 22 21:42:50 RP: khem: I see many changes to the kernel scripts after 3.13.5 (2014-02). Maybe it is just th eold kernel Dec 22 21:43:00 here the two tmp tps://filebin.net/da8oqpoe0wtmjb4q Dec 22 21:43:42 I see the 'expr' error already in do_configure, then in do_compile Dec 22 21:54:46 khem, ah, maybe I have one pointer Dec 22 21:55:13 the build fails on arch/mips/kernel/r4k_fpu Dec 22 21:55:30 that file is full of GCC tests Dec 22 21:55:53 and I spot that <------>.set<-->mips3 Dec 22 22:00:23 ant_home: can you grep for expr use in the sources Dec 22 22:07:23 khem, what if I say there aren't any Dec 22 22:08:12 ok Dec 22 22:08:38 mips/kernel/r4k_fpu.S:83: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f0,272+0($4)' Dec 22 22:08:55 thats the problem Dec 22 22:09:41 see, there are two gcc patches in their sources, one for 4.9 and one for 5 Dec 22 22:09:48 touching that file Dec 22 22:09:50 https://github.com/vu-plus/meta-vuplus/tree/master/recipes-bsp/linux/linux-vuplus-3.13.5 Dec 22 22:10:08 I think it is just a bad kernel Dec 22 22:10:24 somehow patched to build with glibc Dec 22 22:10:29 tc Dec 22 22:10:49 ant_home: https://github.com/vu-plus/meta-vuplus/blob/master/recipes-bsp/linux/linux-vuplus-3.13.5/linux-3.13-gcc-4.9.3-build-error-fixed.patch needs to be done for musl Dec 22 22:11:35 ah, the grep fails Dec 22 22:11:40 its only checking for mipsel-oe-linux-gcc but for musl it will be mipsel-oe-linux-musl-gcc Dec 22 22:11:46 yep Dec 22 22:12:01 but thats a crappy way of getting version Dec 22 22:12:05 he he Dec 22 22:12:16 on top, fixes for gcc7 and mines for gcc8 Dec 22 22:12:21 my eyes bleed looking at such code Dec 22 22:12:23 :/ Dec 22 22:12:54 I plan to try a 4.20 generic bmips + kexecboot cpio Dec 22 22:13:12 the bcm dtb are on their site Dec 22 22:14:02 khem, ah, while you're there, just a note Dec 22 22:14:47 https://github.com/OpenPLi/openpli-oe-core/commit/b87f4e41e486ce057609f8e3e4f0d85b7b82ea07 Dec 22 22:15:00 ^ cross-localedef-native issues with old glibc Dec 22 22:15:25 is it fixed in recent glibc versions? they are moving to sumo Dec 22 22:16:47 ah , soory, it was two commits before Dec 22 22:17:13 khem, "This is a poor design choice by the OE-developers/" Dec 22 22:17:24 ? Dec 22 22:17:37 ant_home: add this to .S file #define GCC_VERSION = (__GNUC__ * 1000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) Dec 22 22:19:41 #define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__) Dec 22 22:19:44 is right one Dec 22 22:21:38 right Dec 22 22:22:35 just with this it still fails Dec 22 22:22:59 I adapt now the above patch Dec 22 22:23:48 let me clean Dec 22 22:24:09 ant_home: and in arch/mips/Makefile remove the orginal change completely Dec 22 22:24:11 and add Dec 22 22:24:21 ifneq ($(call as-option,-Wa$(comma)-msoft-float,),) Dec 22 22:24:23 cflags-y += -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float Dec 22 22:24:25 endif Dec 22 22:24:27 thats it Dec 22 22:25:06 and that will do it Dec 22 22:27:56 you can also fix the grep to include musl gcc and that will do it as well Dec 22 22:28:38 but that patch is as bad as it can get Dec 22 22:28:46 I think its better to fix it properly Dec 22 22:28:50 while you are here Dec 22 22:29:24 yes, first I must backport the fix for the warnings Dec 22 22:29:40 SYSCALL_DEFINE Dec 22 22:29:53 log is annoying Dec 22 22:33:10 RP: core-image-sato-sdk-ptest fails with | RESULTS - gcc.GccCompileTest.test_gpp2_compile - Testcase 1142: FAILED (0.69s) Dec 22 22:35:04 RP: gcc errors while compiling gpg2 like https://8n1.org/14247/3e0e Dec 22 22:35:35 khem, it builds now, thanks. BTW is it a 'fake' FPU on this mips? Dec 22 22:36:31 no, it just ensures that assembler has support for set fpu Dec 22 22:37:07 I somehow read somewhere fpu can be 'emulated' Dec 22 22:37:16 on certain mips Dec 22 22:37:34 must read better :) Dec 22 22:38:54 khem: thanks, typo fixed. Sorry about that Dec 22 22:39:30 khem: the test issue is just from the glibc-version change? :( Dec 22 22:42:43 RP: i have two variants it could be gcc9 as well but the error is more like libstdc++ missing Dec 22 22:43:27 khem: I'm guessing that libc override doesn't work with a cross recipe :( Dec 22 22:43:46 khem: I thought it was a simple tweak. We'll have to go old school and use tclibc Dec 22 22:44:19 khem: I keep meaning to test but getting distracted today :( Dec 22 22:45:57 RP: yes if we differentiate, we need to do it across all kind of cross Dec 22 22:46:04 including crosssdk Dec 22 22:49:38 khem: I'll work on revising it but probably Monday at this point... Dec 22 22:52:35 khem, any known recpe remaining that fails with musl? Dec 22 22:53:23 in my builds I have already switched to musl, take less time Dec 22 22:54:01 it is just that for the legacy toys the advertised size-gain is minimal if not null Dec 22 22:54:07 speed to be tested Dec 22 23:41:57 ant_home: its at par with glibc on most of arches Dec 22 23:43:00 ant_home: always look here http://jenkins.nas-admin.org/job/oe_world_qemux86/ Dec 22 23:43:06 thats musl based x86 build Dec 22 23:43:48 http://errors.yoctoproject.org/Errors/Build/74108/ Dec 22 23:44:17 maybe fix firefox before I get to it :) Dec 22 23:45:44 omg it's all red... Dec 22 23:49:45 khem, is it normal proprietary modules are packaged in an executable ELF initrd? Dec 22 23:50:01 normal for mips maybe? Dec 23 00:39:23 yeah depends Dec 23 00:57:44 RP: khem: any holiday TC update would be tested and fixed by robert and WR China team. Dec 23 00:59:27 * vmeson pulls in the 2.28 typo fix and kicks off an all qemu * (glibc|musl) build Dec 23 01:22:36 vmeson: thats a good point, it will keep our blood pressure low Dec 23 01:24:34 I guess it's more a question of whether you and RP are willing to look at and integrate any fixes rather than take time off. Dec 23 01:25:59 I'll be working and saving personal holidays for another time. Dec 23 01:38:54 sure we can fix a bit **** ENDING LOGGING AT Sun Dec 23 03:00:00 2018