**** BEGIN LOGGING AT Tue Jun 11 02:59:58 2013 **** BEGIN LOGGING AT Tue Jun 11 06:41:24 2013 Jun 11 07:31:21 GNUtoo-x60: hi, time for some more experiment with kexec-tools? Jun 11 07:31:29 hmmm Jun 11 07:31:33 I'm in a train Jun 11 07:31:41 not now ofc ;) Jun 11 07:31:44 so the "desk" here is qiute limited Jun 11 07:31:53 but maybe in 3 days Jun 11 07:31:58 because I'm travelling Jun 11 07:32:03 and I've the build laptop with me Jun 11 07:32:08 I see Jun 11 07:32:12 so when I arrive I could do stuff Jun 11 07:32:24 I should make a howto somewhere Jun 11 07:32:32 I'd like to hear your opinion about a 'weird' matter Jun 11 07:32:37 although I've an issue: Jun 11 07:32:39 ok Jun 11 07:32:49 I have prepared 2.0.4 but have a final linker issue... Jun 11 07:33:17 it is because I patch a Makefile and switch CC with LD Jun 11 07:33:32 beacause some options are unknown to kcc :/ Jun 11 07:33:35 *klcc Jun 11 07:33:47 .but in this way I think I'm breaking linking Jun 11 07:34:06 it's a strange failure... almost no log Jun 11 07:34:59 take your time now, I'll send you an email this evening Jun 11 07:35:48 ok Jun 11 07:36:06 send the email now Jun 11 07:36:09 I'm in Italy Jun 11 07:36:16 and I don't have a french sim Jun 11 07:36:23 so once the train crosses the border Jun 11 07:36:30 I won't have internet anymore Jun 11 07:36:39 argh... I'm in office right now Jun 11 07:37:00 anyway, it's similar to this: http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/kexec/kexec-tools-klibc-2.0.2/purgatory_flags.patch Jun 11 07:37:46 but 2.0.4 added some more flags Jun 11 07:38:05 ah ok Jun 11 07:38:13 it's upstream that changed that stuff....ok Jun 11 07:38:16 I hate this purgatory... for me it will be heaven ..or hell :p Jun 11 07:38:23 lol Jun 11 07:39:12 what's the practical issue? Jun 11 07:39:42 if you revert this patch klcc finds unknown optins i.e. --no-undefined, ... Jun 11 07:40:13 strange indeed Jun 11 07:40:26 see http://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/purgatory/Makefile Jun 11 07:40:54 I see 2 possibilities Jun 11 07:40:55 1) the flag is a dependency of a new flag Jun 11 07:41:02 ..if I remove -Wl form -Wl,--no-undefined it goeas further but breaks later.. Jun 11 07:41:24 or CC->LD breaks it because it's not an LD flag Jun 11 07:41:33 I did split Jun 11 07:41:35 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ Jun 11 07:41:37 but a compiler flag for instance Jun 11 07:41:40 in two lines Jun 11 07:41:46 $(CC) $(CFLAGS) -o $@ $^ Jun 11 07:41:55 $(LD) $(LDFLAGS) -o $@ $^ Jun 11 07:42:03 ah, so what are the comments doing? Jun 11 07:42:11 how should I interpret them? Jun 11 07:42:16 but I have to comment the first one because of unknown compiler switches Jun 11 07:42:25 ok Jun 11 07:42:36 ah, right.. the line #67 is commented ... ? Jun 11 07:42:40 so to recap: Jun 11 07:42:57 $(CC) $(LDFLAGS) -o $@ $^ creates the issue when you uncomment it? Jun 11 07:43:04 yes Jun 11 07:43:26 and in the patch I've only 21 lines Jun 11 07:43:47 also note that I didn't sleep last night at all Jun 11 07:44:05 heh, I've stopped at 2 o'clock too Jun 11 07:44:08 (I had to pack my stuff, and the packing took longer than expected....) Jun 11 07:44:37 so to recap, I *think* this patch is what needs to be fixed Jun 11 07:44:41 (when I wait too much to go to bed I don't sleep at all) Jun 11 07:44:53 ok Jun 11 07:45:09 so the patch workarrounds it? Jun 11 07:45:15 or does it breaks it? Jun 11 07:45:39 this kind of patch was enough for 2.0.2 but not for 2.0.4 Jun 11 07:45:45 ahh ok Jun 11 07:45:58 so there is something more Jun 11 07:46:11 is it possible to build fast on that machine: Jun 11 07:46:23 model name : Genuine Intel(R) CPU T2300 @ 1.66GHz Jun 11 07:46:25 ? Jun 11 07:46:46 are there shortcuts? Jun 11 07:46:54 because my laptop here is slow Jun 11 07:47:05 and the other one is too big for the train tablet Jun 11 07:47:23 Intel® Core™ Duo Processor T2300 (2M Cache, 1.66 GHz, 667 MHz FSB) Jun 11 07:47:35 indeed Jun 11 07:47:39 2M cache is not that much but still... Jun 11 07:47:55 and lack of Vitualization.... Jun 11 07:47:58 that's my main issue Jun 11 07:48:03 I observed big difference btw a core2 2.4 and a xeon quad 2.4 Jun 11 07:48:08 ok Jun 11 07:48:13 cache is a factor there Jun 11 07:48:16 ok Jun 11 07:48:29 still much better than building on an old dual PIII Jun 11 07:48:55 also another problem would be that: Jun 11 07:48:58 /dev/mapper/root 333G 187G 129G 60% / Jun 11 07:49:24 thats' enough I'd say Jun 11 07:49:34 or maybe I should just get the other laptop and see if it fits? Jun 11 07:50:49 no, if you are traveling it's bothering to transport Jun 11 07:50:53 ;) Jun 11 07:52:31 else I could build for x86 and skip the toolchains? Jun 11 07:52:48 because that's what eat all the time.... Jun 11 07:54:01 I should push more into meta-mainboard and add it as a layer Jun 11 07:54:07 I mean submit it Jun 11 08:00:16 yes, klibc-native on x86 is also a way. Just install the headers under /lib/klibc and not /usr/lib/klibc Jun 11 08:00:43 (as we do in sysroot iirc) Jun 11 08:02:33 one last thing...I've removed vmcore-dmesg form the targets..it fails on klibc:/ Jun 11 08:03:10 the problem is klibc lacks imaxdiv_t imaxdiv_sec, imaxdiv_usec Jun 11 08:03:53 I got a suggestion: you could switch it to ldiv_t if not C99/GCC easily enough Jun 11 08:04:53 but really we don't need this binary atm Jun 11 09:29:25 bluelightning: about that cramfs patch for collie, better to put it in recipes-devtools and not in recipes-support ? Jun 11 09:29:59 strangely I have had any feedback Jun 11 09:30:24 ant_work: it's not really clear... probably doesn't matter Jun 11 09:30:49 ant_work: yes :/ it may be worth sending another ping Jun 11 15:39:30 bluelightning: I'm trying to convincer Saul with private mail :) Jun 11 15:41:04 ant_work: I'd say keep it on the list, more chance of other users chiming in Jun 11 15:43:13 k **** ENDING LOGGING AT Wed Jun 12 02:59:58 2013