**** BEGIN LOGGING AT Tue Sep 18 02:59:59 2012 Sep 18 06:11:20 good morning Sep 18 06:31:42 morning Sep 18 06:35:41 Good morning Sep 18 06:44:11 pb_: good morning. I have a weird glibc/mmap ARM vs. x86 question Sep 18 06:44:53 pb_: 1.) for (;;) munmap(mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)); Sep 18 06:45:46 pb_: on x86 (3.2.0 debian) i always get the same address.. on arm (3.2.29) i get randomized addresses (a small range) Sep 18 08:14:39 morning all Sep 18 08:17:00 morning all.. how do i exclude the kernel image (/boot/uImage*) from the rootfs in oe-core?? Sep 18 08:17:19 i've found dozen of ways to do it in classic, but so far none to do it in oe-core Sep 18 08:18:00 it seems module.bbclass is pulling it in as a dependency (why it does that is currently beyond me, but accepting that as a fact) Sep 18 08:18:45 gmc: two things Sep 18 08:18:48 RDEPENDS_kernel-base = "" Sep 18 08:19:01 where would i put that line? Sep 18 08:19:13 i have that in my image .bb file now, but with no effect Sep 18 08:20:10 gmc: no, it needs to be in your local config or more properly in your distro config Sep 18 08:20:42 allright.. actually, i don't have a distro at the moment :) Sep 18 08:21:03 right, local.conf will suffice temporarily Sep 18 08:21:17 but creating your own distro config isn't too tricky Sep 18 08:21:18 i should probably start defining a distro though Sep 18 08:21:39 module.bbclass is unconditionally adding an RDEPENDS on kernel-image, yes... I'm not sure that's always desirable Sep 18 08:22:20 i would understand a DEPENDS, an RDEPENDS is semantically incorrect i think.. Sep 18 08:22:58 well, no, it's a correct statement (kernel-image is a package so it's a valid runtime target) Sep 18 08:23:12 well yes, but you don't need the kernel image to load a module Sep 18 08:23:27 you just need it booted.. it doesn't have to be on the same filesystem, or on a filesystem at all Sep 18 08:23:28 it already DEPENDS on virtual/kernel, that takes care of build time Sep 18 08:23:40 right, I'm also unclear on why it would be needed Sep 18 08:23:45 anyway, philosophical discussion :) Sep 18 08:24:06 well, I think these things are worth looking at if they can be improved Sep 18 08:24:20 one thing i'm also struggling with is how to build different variants of the same 'distro' so to speak, but for slighlty different targets Sep 18 08:24:41 by different targets do you mean different machines? Sep 18 08:24:51 bluelightning: true, improvement is good, but i'm not qualified at this point to suggest a solution,can only point at potential issues :) Sep 18 08:24:59 no, not really different machines.. Sep 18 08:25:08 slightly different instantiations of the same machine.. Sep 18 08:25:25 the canonical way would be to make it different machines.. Sep 18 08:25:44 well, it depends on whether "instantiations" means different features in the hardware or not Sep 18 08:25:45 but they only differ in some external hardware hooked up to the soc pins and a slightly different rootfs Sep 18 08:25:56 if not, it's not really a different machine config situation Sep 18 08:26:12 ok, could be multiple machine configs then Sep 18 08:26:32 yep.. that's how i would do it initially Sep 18 08:26:58 but it can be quite convenient to be able to have, say, two image recipes 'foobar-a-image.bb' and 'foobar-b-image.bb'.. Sep 18 08:27:13 so you can simply build them from within the same oe environment without having to change local.conf Sep 18 08:27:37 if the differences are in terms of package selection that's perfectly doable Sep 18 08:27:59 it's only when the hardware differences imply some recipe compilation difference that that won't work Sep 18 08:28:08 package selection, but also kernel config, u-boot config, and some subtle changes in eg base-files and netbase Sep 18 08:28:39 so there's actually two kernels, one for a and one for b.. and that complicates matters a bit (what with preferred-provider for virtual/kernel and all) Sep 18 08:28:56 ok, that's probably not going to be possible out of the box - we only support one PREFERRED_PROVIDER_virtual/kernel for example Sep 18 08:29:40 yep, that's why i'm struggling :) i'm going to think about it some more.. Sep 18 08:29:41 the best fit at the moment would be separate machine configs Sep 18 08:29:52 but with some engineering it could be possible Sep 18 08:31:44 the question being whether the engineering effort outweighs the slight benefit of not having to edit local.conf Sep 18 08:31:58 i'm undecided on it, but external forces push me the other way :) Sep 18 08:33:04 could probably set the preferred providers dynamically based on the PN we're building or something, although it feels a bit hackish Sep 18 08:36:02 bluelightning: tnx for hearing me out again! i can move ahead with more confidence now that i've not missed something really obvious :) Sep 18 08:36:31 np Sep 18 08:36:53 it's worth noting that module.bbclass is only used for external modules (I guess you probably know that already though) Sep 18 09:16:44 i guess i have to remove everything and rebuild from scratch when changing to a distribution? Sep 18 09:20:24 gmc: depends on whether you are using master with BB_SIGNATURE_HANDLER = "OEBasicHash" or otherwise how much that distro deviates from what you already built with Sep 18 09:22:03 i'm mostly wondering because it doesn't pick up the RDEPENDS_kernel-base thing.. Sep 18 09:22:22 it does parse the distro conf though, because if i inject garbage i get a syntax error for the file Sep 18 09:23:14 Everything is parsed, regardless of what target you make. Sep 18 09:23:45 (Haven't been following the conversation, just throing myself in here :p) Sep 18 09:24:01 ah so there is a chance it is somehow not picking up my distro conf then? Sep 18 09:27:40 gmc: if you have BB_SIGNATURE_HANDLER = "OEBasic" it won't force rebuilds due to variable values changing Sep 18 09:28:25 gmc: in which case you need to force the rebuild manually either by bumping PR or bitbake -c clean virtual/kernel Sep 18 09:29:23 I have the habit of just deleting the whole world and rebuilding overnight whenever anything like this pops up :p Sep 18 09:30:00 i am not aware of having changed BB_SIGNATURE_HANDLER so i'm guessing i have the default Sep 18 09:36:08 gmc: you can double check just by doing: bitbake -e | grep ^BB_SIGNATURE_HANDLER Sep 18 09:37:15 interesting setting that, BB_SIGNATURE_HANDLER Sep 18 09:38:46 fairly low-level Sep 18 09:39:17 Using the hashed variant triggers a lot of rebuilds, potentially? Sep 18 09:41:16 Are there other options than basic and basichash? Sep 18 09:48:53 xim: yes, if the change is lower down in the chain it can force a lot of rebuilds; that may often be the right answer Sep 18 09:49:20 xim: there aren't any other options no, but OEBasicHash does have some policy which stops certain things from changing the hash Sep 18 09:49:34 for example changes to quilt-native won't force everything to rebuild Sep 18 09:52:46 bluelightning: Cool, nice to know =) Sep 18 11:15:09 any hints on building an SDK with openembedded-core? pointers to docco? or an example? Sep 18 12:07:08 hi all Sep 18 13:21:06 hi all Sep 18 13:28:39 which binutils does nativesdk-eglibc use for linking? Sep 18 13:28:53 host one, binutils-native one? binutils-nativesdk one? Sep 18 15:32:24 tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-oesdk-linux.gcc-crosssdk-initial/gcc/x86_64-oesdk-linux/4.7.2/ld - from which package it came? Sep 18 16:12:15 JaMa: around ? Sep 18 16:13:44 hrw: it should be an intermediate artifact created by gcc-crosssdk-initial Sep 18 16:15:04 khem: or binutils-crosssdk Sep 18 16:15:35 khem: switched from 2.23.51.20120918 to 2.22 == nativesdk-eglibc compiled Sep 18 16:23:20 hrw: I am missing context Sep 18 16:23:27 are you trying my 2.23 patches ? Sep 18 16:23:44 hrw: or some linaro binutils Sep 18 16:38:28 khem: I have meta-aarch64 layer where I have binutils-git, gcc with ARM/aarch64-4.7-branch, linux-libc-dev from aarch64 tree etc Sep 18 17:06:47 hrw: ok Sep 18 17:51:30 does anyone build test against the oe-core distro? Sep 18 18:48:34 Does anyone know where I can get a simple Source code that I could GCC and run a little anything in linux mint/ Sep 18 18:51:25 ? **** ENDING LOGGING AT Wed Sep 19 02:59:58 2012