**** BEGIN LOGGING AT Fri Mar 16 03:00:02 2018 Mar 16 06:21:42 New news from stackoverflow: OS Updating in Yocto Mar 16 09:12:43 hello, can I use SRC_URI to fetch a binary blob from a locally mounted Samba share (using file://) ? Mar 16 09:14:06 here is my recipe: https://pastebin.com/qqeQBpqv Mar 16 09:14:22 it does not seem to work, although the fetch stage does not fail Mar 16 09:15:34 when I check stuff in tmp/work, it does not contain the firmware file Mar 16 09:18:14 eduardas_m: That should work, although the fetcher might end up not copying local files as an optimization Mar 16 09:20:13 neverpanic: this is the error that I get: https://pastebin.com/nuvmmmdL Mar 16 09:23:36 neverpanic: oh, it seems the blob is not copied directly to the work directory, but inside a certain directory hierarchy Mar 16 09:25:14 it appears under tmp/work/all-fod-linux/amped-rf-firmware/161215D-r0/home/eduardas/NAS_SOFTWARE/linux/binary_blobs/amped_rf/BT53H_161215D.bin Mar 16 09:25:39 honestly, that was kind of counter-intuitive for me Mar 16 09:26:36 what is the point in replicating the full local path inside tmp/work? Mar 16 09:27:45 files from different directories could have the same names, leading to conflicts? Mar 16 09:27:58 there's probably a flag you can set to determine the output file name Mar 16 12:52:53 New news from stackoverflow: Building packages to yocto image (image) without using recipes Mar 16 14:46:58 If I may ask :) Mar 16 14:47:27 My recipe is producing static library -> libfoo.a Mar 16 14:47:32 no libfoo.so Mar 16 14:47:44 It is correctly placed in /usr/lib/ Mar 16 14:47:57 on foo//image Mar 16 14:48:18 if I build image wihich includes: include image_class.bb Mar 16 14:48:48 I do need to put Mar 16 14:48:48 RDEPENDS_${PN}-staticdev = "${PN}-dev" Mar 16 14:48:48 RDEPENDS_${PN}-dev = "" Mar 16 14:48:48 in the recipe file Mar 16 14:49:24 then, when I add foo-staticdev to packageroup Mar 16 14:49:29 the libfoo.a is installed Mar 16 14:49:43 Why there is a dependency between -dev and -staticdev? Mar 16 14:49:54 some projects produce only static libraries Mar 16 14:50:08 Can somebody know what was the rationale behind this? Mar 16 15:49:09 lukma: do you mean why is there a dependency on -dev from -staticdev? Mar 16 15:49:22 rburton: Yes Mar 16 15:49:32 because a staticdev is no good without the headers which are in the -dev Mar 16 15:49:51 Ach , ok, so headers are integral part of -dev Mar 16 15:50:08 you *could* put the headers in the staticdev but that would just cause more pain and be unexpected behaviour Mar 16 15:50:41 I'm really wondering what your usecase for shipping a *.a file in an image is, though. Mar 16 15:50:43 rburton: And why I need to put this line in my recipe? Mar 16 15:50:44 RDEPENDS_${PN}-dev = "" Mar 16 15:50:44 To erase the -dev package (if I only produce *.a library) Mar 16 15:51:13 because we assume that you generate a PN Mar 16 15:51:16 if you don't then unset that Mar 16 15:51:39 the staticdev -> dev dependency is a default one so you can drop that from the recipe Mar 16 15:52:16 neverpanic: I do have a project which produces *.a as its output..... Mar 16 15:52:34 at least this is what I got after following README and default cmake settings Mar 16 15:52:38 lukma: Sure, but what's the point of having that on the image? *.a files are static libraries, so you'd need a compiler to use them? Mar 16 15:52:52 if its a development image for building *on* that makes sense Mar 16 15:52:57 otherwise its a massive waste of space Mar 16 15:54:09 rburton: Those *.a libraries could be : Mar 16 15:54:09 1. used on the target image for building (rare case) or Mar 16 15:54:10 2. *.a would be a part of eSDK/SDK Mar 16 16:28:35 hello, how to modify the rootfs format in order to have it in tgz format ? Mar 16 16:28:47 Is there any workaround / fix for https://lists.yoctoproject.org/pipermail/yocto/2017-September/038036.html Mar 16 16:28:50 Point 2 ?> Mar 16 16:29:10 The "ERROR: Unexecuted tasks found in preparation log:" in eSDK Mar 16 16:30:16 vladzouth: something like IMAGE_FSTYPES += " tar.gz" in your image recipe Mar 16 16:30:57 vladzouth: note the space right before tar.gz Mar 16 16:32:38 what is the proper way to have a production kernel and a testing kernel in my BSP... do I need to create a machine definition for each case or is there a better way? Mar 16 16:34:01 because I do not need DEBUG_FS enabled for production use for example, but that is useful to have if I want to use powertop during development Mar 16 16:35:44 eduardas_m: i did this in my local.conf but it does'nt change anything i still have rootfs in tar.bz2 format Mar 16 16:37:03 vladzouth: can you paste your local.conf to pastebin? Mar 16 16:39:26 eduardas_m: here is the link https://pastebin.com/9kUh2zq5 Mar 16 16:39:33 vladzouth: are you sure your image was rebuilt? I usually am paranoid and do a "bitbake -c cleanall" and only then a "bitbake " Mar 16 16:40:23 vladzouth: missing "S" Mar 16 16:40:42 vladzouth: "IMAGE_FSTYPES" Mar 16 16:40:59 vladzouth: not "IMAGE_FSTYPE" Mar 16 16:42:03 vladzouth: bitbake does not say anything about variables you add that have names it does not process and then eventually do not get used Mar 16 16:42:26 edeouardas_m: Ok, thank you! Mar 16 16:42:39 quite sad, since it really does not catch cases when variables simply get misspelled Mar 16 16:42:55 happened to me too Mar 16 16:43:18 vladzouth: no problem Mar 16 16:47:16 eduardas_m: it still generate the rootfs in tar.bz2 format. is there anything else to add? Mar 16 16:48:04 Any of you had any experience with using Azure for yocto builds? Mar 16 16:50:47 vladzouth: it should still generate tar.bz2 if the image recipe you are using demands it, but if you add IMAGE_FSTYPES += " tar.gz" to local.conf, you should also get tar.gz in the deploy directory Mar 16 16:53:17 vladzouth: += means it will still generate all image types you used to generate previously Mar 16 16:54:31 vladzouth: just now you should get an additional one... are you sure there really is no tar.gz in deploy/images directory? I would find it kind of odd Mar 16 16:54:50 Ok i am going to look at my local.conf if there is something that i miss Mar 16 16:56:46 eduardas_m: there is modules file which is in tgz format but nothing else Mar 16 16:57:41 vladzouth: try bitbake -e | grep IMAGE_FSTYPES and tell what you get Mar 16 16:58:30 vladzouth: if there is no tar.gz in the output, it means four addition to local.conf does not become valid for some reason Mar 16 16:58:52 "your addition", I mean Mar 16 17:00:32 also, my solution works on Yocto 2.4, not sure since which Yocto release tar.gz is a valid image type Mar 16 17:00:55 eduardas_m: here is the result https://pastebin.com/ikpKsBic Mar 16 17:03:08 RP: hmm, not sure if this'd be useful or not: https://gist.github.com/kergoth/9796665eca00096fdf54096e11b989c9 - searches paths for pathnames matching the specified wildcards, still returning just the first for each, relative to the search path. might be a better way to handle wildcards in file uris. I just used it to improve my class that grabs postinst intercepts from layers. function arguments align with shutil.which() Mar 16 17:03:54 vladzouth: on line 11 there is IMAGE_FSTYPES="tar.bz2", if your addition in local.conf would get processed, you should have gotten IMAGE_FSTYPES="tar.bz2 tar.gz".. at least I would expect that Mar 16 17:05:36 eduardas_m: haa, so the bitbake parsing variable isn't work well Mar 16 17:05:43 vladzouth: not really sure why bitbake could ignore stuff in local.conf if it is written correctly Mar 16 17:06:53 vladzouth: bitbake -e |less, search for IMAGE_FSTYPES, then scroll up a bit and you'll get a breakdown of what assignments happened. Mar 16 17:07:04 vladzouth: my guess is your += in local.conf gets overwritten by a BSP which uses = Mar 16 17:07:10 (and is parsed after local.conf) Mar 16 17:07:17 so the solution would be to use _append in local.conf Mar 16 17:08:00 eduardas_m: Ok, i am going to try that. Mar 16 17:09:26 rburton: is that the same thing for all variable in local.conf? Mar 16 17:10:34 rburton: I honestly kind of always assumed local.conf takes top priority during parsing... so it can be overriden by a recipe after all? then what priority does local.conf actually have? Mar 16 17:10:53 eduardas_m: read bitbake.conf to find out Mar 16 17:10:58 (it doesn't happen last) Mar 16 17:11:13 because it sets default values for a lot of things... Mar 16 17:11:24 rburton: useful info, thank you Mar 16 17:11:33 ok, i understand. Mar 16 17:11:58 i confirm, it works ! Mar 16 17:12:06 thank you ! Mar 16 17:56:37 are all of you running yocto builds on your own metal, or does any of you use any cloud computing for it? Mar 16 18:02:31 sveinse, I've heard of people using cloud machines Mar 16 18:02:45 especially for intermittent use, so they can leave it off a lot Mar 16 18:04:20 Crofton: Yeah. I've been analyzing our computing needs and with proper on/off control, it can we worth it Mar 16 18:04:58 Esp. as our IT deparment don't want anything else than windows in their farm, so our Linux buildserver is being frowned heavily upon. Mar 16 18:17:28 jesus Mar 16 18:17:40 IT departments are a curse on productivity Mar 16 18:30:08 Crofton: yeah. I'm working in a non-linux/unix work environment, so we're pretty alone with this product Mar 16 18:37:57 my build stuff is mostly local on my laptop, if i were doing more, i might well be using cloud stuff. Mar 16 20:05:15 kergoth: interesting. We do need to track where we searched even if we didn't match too... Mar 16 20:06:16 kergoth: [so we can change the hash if some file appears earlier in the search path meaning we need to rebuild] Mar 16 20:09:52 RP1: yep, it does. there's a history/candidate list for each file found by the globbing Mar 16 20:10:17 basically just a wildcard/glob version of our existing which() Mar 16 20:11:52 hmm Mar 16 20:16:10 kergoth: ok, I'm not thinking straight with travel at this point ;-) Mar 16 20:16:44 no worries, just did it on a whim and figured i'd get an opinion, i'll open an issue Mar 16 21:06:14 Hi, I added another meta-layer where I am trying to add to oeqa, i have a /lib/oeqa/controllers path. If I include this layer, do_testimage fails complaining that it cant find module oeqa.core because its looking in my layer and not seeing a oeqa/core. pretty sure this is whats happening because if I dont include this layer in the bb file, its runs fine. think i am missing something, any ideas? Mar 16 21:22:04 Hello, folks. Got a question about yocto and pre-built cross-toolchain. My task is to make it being part of the build system as if one was built internally. I have already successfully followed the linaro-toolchain way, but it wasn't really what I needed. I want to completely embed my toolchain to yocto as fully available set of binutils/gcc/glibc/etc packages. As far as I could find, my toolchain can be split into Mar 16 21:22:04 binutils-cross (->mips), binutils-cross-canadian (x86_64->mips), gcc-cross (mips), gcc-cross-canadian (x86_64->mips), gcc-runtime (mips), libgcc (mips), libgfortran (mips), glibc-* (mips). I already got the concept of the target packages, there are no problems with it, but I am stuck with cross/cross-canadian and shared states part. Particularly I don't understand how to use the installation paths and default vars like Mar 16 21:22:04 ${libdir}, ${bindir} and so. As far as I can see cross{-canadian}.bbclass redefines the these variables so one got to be a !absolute! paths with base of STAGING_DIR_NATIVE. Could you tell me why does the gcc-cross recipe stages files with absolute path??? Mar 16 21:24:47 fancer: meta-external-toolchain now uses separate recipes for each external toolchain component Mar 16 21:24:52 It also seems weird, when gcc-cross.inc uses combinations like: "${D}${libexecdir}/gcc/${TARGET_SYS}/${BINV}/", but for cross.bbclass base recipe ${D} is still the absolute destination directory and ${libexecdir} shall be expanded to ${STAGING_DIR_NATIVE}${prefix_native}/libexec/${CROSS_TARGET_SYS_DIR} Mar 16 21:25:03 don't think there's much cross-canadian there yet, but it's doable Mar 16 21:27:47 kergoth: Cool! Thanks. It seems I got old linaro metas without packages splitting. I'll take alook there then. Mar 16 21:28:41 https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-external, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-external/gcc/gcc-external-cross.bb, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/recipes-external/gcc/libgcc-external.bb Mar 16 21:28:57 it's not perfect, but i think it's better than shoving everything into one monolithic recipe Mar 16 21:29:16 Yeah, that's why I almost got it myself.) Mar 16 21:29:16 the cross recipes write links/wrappers to the toolchain bindir, so there's no need to override TARGET_PREFIX anymore Mar 16 21:31:15 hmm, forgot to move the nopseudo bits from meta-external-toolchain to meta-sourcery when i split the layers Mar 16 21:31:58 the intention is meta-external-toolchain is the bits that are generic to any toolchain, while you can create another layer that builds on it for the particularities of the individual toolchain, which is what meta-sourcery is now for the Sourcery G++ toolchain Mar 16 21:32:11 i dont' think anyone else has tried basing their toolchain support on the new layer yet Mar 16 21:32:22 would be glad to hear any feedback on it Mar 16 21:33:06 hmm, need to update the readmes, too Mar 16 21:35:18 Yeah, it would be good to have any docs about the external toolchain embedding. I got nearly crazy trying to figure out how to do it. Hope the new meta-external-toolchain will d the trick. Did you test it with something else rather than with Sourcery G++ toolchain? Mar 16 21:35:40 I got NG-toolchain bits. Mar 16 21:36:14 * crosstool-NG Mar 16 21:36:17 not recently, but i've done so in the past, i.e. started in-progress work on supporting crosstool-ng-built toolchains. but it's been a while, so there could be kinks Mar 16 21:37:25 the downside to the broken-up-recipe approach is we can't just swipe the majority of the external toolchain sysroot and package what we want, instead it pulls just the files we need for each recipe, so some of the recipes end up with more detailed explicit lists of individual files to include, like glibc's headers. but i think that's for the best too, as annoying as it is to explicitly list everything Mar 16 21:38:12 fyi, with current meta-external-toolchain, it uses the FILES_ variables both for what to package and what files to extract from the xternal toolchain sysroot, so you can just list those files once instead of having to do both do_install *and* the files bits for subpackaging, the way we used to have to do in the monolithic setup Mar 16 21:38:19 tradeoffs, but i think it's still a net gain Mar 16 21:39:33 most of my time is spent dealing with sourcery & meta-mentor, of necessity, since that's my company's priority.. Mar 16 21:39:55 i would definitely like to see support for crosstool-ng working, ideally both external and internal (i.e. a recipe that builds a crosstool-ng toolchain from source) Mar 16 21:40:33 Yeah, that's what I did. I analyzed all the bits, created the files with lists if pairs: source file - install path, then created a small shell-function, which copies the source files to the ${D} directory with prefix like lib/, usr/lib, etc. Mar 16 21:40:59 * kergoth nods, not a bad approach Mar 16 21:41:34 i ended up doing the extraction and copy in an approach which is similar to how bitbake's fetcher works. it checks multiple search paths and also has "mirror" support, to check alternate locations, i.e. sbin vs bin Mar 16 21:41:43 to try to handle any arbitrary toolchain Mar 16 21:42:14 The only problem was a lot of hand-working.) Mar 16 21:42:37 * kergoth nods Mar 16 21:44:02 If only crosstoolhain-NG supplied such a list of files.) At least it usually with executable like: bin/mipsel-unknown-linux-gnu-ct-ng.config, which prints the whole toolchain config. Mar 16 21:45:31 So we can extract components versions and another useful things. Mar 16 21:45:41 ah, that's very nice indeed Mar 16 21:45:51 i should really talk the sourcery folks into shipping some form of metadata Mar 16 21:47:00 having real info to use rather than having to guess would be better indeed Mar 16 21:47:58 And it's much better than to hard-code the versions to recipes. Mar 16 21:48:15 yep Mar 16 21:48:50 currently meta-external-toolchain does set some versions, i.e. pulls kernel version from the kernel headers, runs gcc -dumpversion, etc. but that doesn't work for everything Mar 16 21:50:30 Yeah, I saw it in previous meta-linaro/meta-linaro-toolchain/conf/distro/external-linaro-toolchain-versions.inc. Mar 16 21:51:51 Copied it to my layer.) Mar 16 21:52:03 * with minor alterations... Mar 16 21:53:13 one more question. Does meta-external-toolchain allow to create an SDK with external toolchain embedded? Mar 16 21:56:39 not yet, though it should be doable without too much work. would be best off adding nativesdk and cross-canadian variants to the recipes, possibly adding additional search paths so it'd extract the toolchain binaries rather than just the files in the sysroots Mar 16 21:59:19 Ahhh, I knew, there couldn't be everything so great.) So what does the meta-external-toolchain basically do with the toolchain bits? Mar 16 22:00:58 Does it copies them to the sysroots without packages creation? Mar 16 22:04:01 For now, creates symlinks / wrapper scripts for the main toolchain binaries. doesn't copy internal components of gcc or binutils. Mar 16 22:04:04 * sorry If I might have sounded rude. I am just very excited, that there is a layer, which does nearly everything, what I tried to create for nearly two weeks... Mar 16 22:04:12 which is appropriate for cross, since cross recipes aren't packaged in any form Mar 16 22:04:33 heh, no problem, hopefully it's at least a starting point for you Mar 16 22:05:03 Yeah, crosses doesn't, but libgcc, libgfortran, gcc-runtime, etc does. Mar 16 22:05:14 and cross-canadians. Mar 16 22:07:04 I'd suggest creating a gcc-cross-canadian recipe which inherits external-toolchain and cross-canadian, then add the toolchain binary path (${EXTERNAL_TOOLCHAIN}/bin) as well as the gcc internal binary paths to the search paths, then set the FILES variables to grab the appropriate files. it's actually even easier than you might think, since you could build gcc-cross-canadian with the internal recipes and then dump the contents of the binary packages and Mar 16 22:07:04 use those lists to set the FILES variables. then only after that adjust the search paths and files mirrors on an as-needed basis to ensure it can find those files in the external toolchain Mar 16 22:08:01 could also build gcc for target and use those packages for the files lists, but the paths might not line up perfectly due to how cross-canadian adjusts the prefix/etc Mar 16 22:12:13 That was the reason I nearly got crazy, when found that cross/cross-canadians do the prefixes redefinition. Mar 16 22:13:22 So my yocto simple targets-based ordered world collapsed.) Mar 16 22:13:22 native does too. it's not ideal, but we used to have issues with path relocation. the main advantage to continuing to hardcode a path is we then have a known location to substitute when we run our relocation process to fix the binaries to run from the new location Mar 16 22:13:30 most projects aren't path relocatable, other than the toolchain itself Mar 16 22:13:44 so we have to fix them up on install Mar 16 22:14:05 i.e. we search/replace the install path in scripts Mar 16 22:14:14 hard to do if the install root was / :) Mar 16 22:14:50 could really epxlicitly set something *invalid* as the default prefix rather than a hardcoded install path default the way we do today (SDKPATH) Mar 16 22:15:26 Yeah, I see. Mar 16 22:16:00 better to patch the upstream projects to be path relocatable, but it's a huge effort and nobody else really cares about it Mar 16 22:16:53 You suggested: "... add the toolchain binary path (${EXTERNAL_TOOLCHAIN}/bin) as well as the gcc internal binary paths to the search paths... " In two words, how can it be done? Mar 16 22:17:12 see external-common.bbclass Mar 16 22:17:21 the two variables that control where it looks for files are defined there Mar 16 22:17:22 Ok, thanks Mar 16 22:19:05 so, lets say you add ${bindir}/${EXTERNAL_TARGET_SYS}-gcc to FILES_${PN}.. obviously that file doesn't exist in the external toolchain in that form.. i.e. not /usr/bin or whatever. so we'd want to 1) make sure ${EXTERNAL_TOOLCHAIN} is in the search paths, so it checks relative to toplevel, and then 2) make sure it checks /bin/ for ${bindir} using the mirrors variable, so it ends up finding ${EXTERNAL_TOOLCHAIN}/bin. Mar 16 22:19:40 if that makes sense Mar 16 22:20:48 it could have used a single list of paths to search, but that'd end up huge and unwieldy, hence the split in two variables, one for the install root / sysroot, the other for the paths relative to that root in the usual form, i.e. bindir, libdir, whatever Mar 16 22:21:24 grabbing just the main gcc binary is actually probably a good starting point as a proof of concept, then can add all the other binaries and the files they need Mar 16 22:22:24 what do you by "mirror variables" ? Mar 16 22:22:39 again, https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/classes/external-common.bbclass Mar 16 22:22:56 https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/classes/external-common.bbclass#n8 = the first variable i mentioned, EXTERNAL_INSTALL_SOURCE_PATHS Mar 16 22:23:06 https://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/tree/classes/external-common.bbclass#n16 = the second variable i mentioned, FILES_MIRRORS Mar 16 22:24:04 looks like it already checks paths relative to the root of the toolchain (EXTERNAL_TOOLCHAIN) Mar 16 22:24:16 and FILES_MIRRORS already checks base_prefix for prefix, i.e. it knows to check /bin for files in /usr/bin Mar 16 22:24:33 so there's a possibliity it might just work as is, but might need to add to FILES_MIRRORS if not Mar 16 22:24:40 * sorry for nuby question, just wanna make sure I grad the whole concept... Mar 16 22:25:00 np, yocto already has a high learning curve, and this layer does things in a unique way on top of that :) Mar 16 22:25:31 tried to make it as simple as possible while easing the creation of recipes and having the minimum flexibility to support different toolchains with different layouts Mar 16 22:27:56 I pretty much understand the way the yocto in general works, but when things get to creating something bigger than just a target recipe like toolchains thing and cross, and I get stuck with so-much-code-and-internal-variables-and-configs... Mar 16 22:28:31 there's a lot of moving parts, so until you see how everything fits together into a whole, it can be pretty confusing Mar 16 22:29:22 Yeah, exactly Mar 16 22:29:47 crosssdk = the toolchain that compiles the binaries that will run on SDKMACHINE, i.e. host binaries for the host sysroot.. i.e. it builds the nativesdk recipes. cross-canadian = binaries that run *on* SDKMACHINE, but target MACHINE, hence cross-canadian, which is a build where BUILD_SYS != HOST_SYS != TARGET_SYS Mar 16 22:30:19 obviously creating cross-canadian recipes that redistribute the external toolchain will assume that the SDKMACHINE (the machine the sdk is installed on) is binary compatible with the host you're building on Mar 16 22:30:39 but that's probably a safe assumption, unless you're redistributing a 32-bit toolchain to a 64-bit host without the 32-bit libraries installed, or something Mar 16 22:30:46 Yeah, I understand that. I have read a lot about cross-compilation and used it since I started by carrier. I meant the yocto internals. Mar 16 22:30:54 ah, fair enough Mar 16 22:31:16 reading bitbake.conf and then each of the recipe variant bbclasses, can be helpful, though you don't always see the rationale without digging into git history :) Mar 16 22:32:19 That's anther way to understand why some things are got to be in a big opensource project - read mailing lists.) Mar 16 22:35:05 by the way, what is meta-external-toolchain compatible with rocko? Mar 16 22:35:57 * s/what//g Mar 16 22:39:34 so I'm still having issue with the permissions of my output files on a native cmake recipe I'm working on Mar 16 22:39:55 and another question. Do I really need the meta-sourcery to be copied into my yocto tree? Mar 16 22:40:16 The cmake_install.cmake output from my recipe has TYPE set to FILE Mar 16 22:40:45 whereas the cmake_install.cmake output from a native build has TYPE set to EXECUTABLE Mar 16 22:41:13 fancer: meta-external-toolchain should work with or without meta-sourcery, the latter builds on the former, not vice versa. and yo udont need to copy anything anywhere, you can put your layers whereever you want, as long as you set BBLAYERS to match Mar 16 22:41:44 Yeah, right. It just easier, when everything in one place.) Mar 16 22:42:15 I mean under one directory, so to have easier searched. Mar 16 22:42:40 fancer: fyi, i just made a teeny tiny gcc-external-cross-canadian that does package up the main binaries, it's 3 lines Mar 16 22:42:46 require recipes-external/gcc/gcc-external.inc Mar 16 22:42:46 inherit external-toolchain cross-canadian Mar 16 22:42:54 FILES_${PN} = "${@'${gcc_binaries}'.replace('${TARGET_PREFIX}', '${bindir}/${EXTERNAL_TARGET_SYS}-')}" Mar 16 22:43:05 gcc-external.inc already lists the binaries, so can just use that Mar 16 22:44:09 Thats awesome!.) Thanks man! The same might be needed to be done for glibc... Mar 16 22:45:09 looks like mine incorrectly picked up the binary paths from ${EXTERNAL_TOOLCHAIN}/${EXTERNAL_TARGET_SYS} rather than the ones in ${EXTERNAL_TOOLCHAIN}, so should probably reorder it for this recipe to fix that: EXTERNAL_INSTALL_SOURCE_PATHS =+ "${EXTERNAL_TOOLCHAIN}" Mar 16 22:45:27 normally EXTERNAL_TOOLCHAIN is the last place it looks, since most recipes want files from the sysroot, not from elsewhere Mar 16 22:45:54 might want to add SDK_ARCH to PN or something, i'd examine gcc-cross-canadian in oe-core for those sorts of minor details Mar 16 22:46:21 obviously there's a ton of other files to grab, not just the main binaries, but this shows it's doable, and you just need the list of files to grab and it should go pretty smoothly from there Mar 16 22:47:05 fancer: we already have glibc. it's a target recipe, so we already package it Mar 16 22:47:42 the environment-setup shipped in the sdk will already set —sysroot= to the target sysroot in the sdk, which already has glibc Mar 16 22:47:57 so all you really need is gcc and binutils for a complete redistributed toolchain in the sdk, in theory Mar 16 22:48:09 Ahhh, right. Mar 16 22:48:09 those being the main -cross recipes involved Mar 16 22:50:21 i can't see how cmake.bbclass so I'm guessing this is done elsewhere, how can I indicated that these files need to be executable? Mar 16 22:51:25 And one more crucial question. Will meta-external-toolchain work with poky distribution? Mar 16 22:51:29 They are generated as executable, but not installed as such. Mar 16 22:51:51 kergoth: did you test it with poky tree? Mar 16 22:52:04 or it doesn't matter? Mar 16 22:52:05 not sure what you mean by that Mar 16 22:52:15 poky is bitbake+oe-core+meta-poky Mar 16 22:52:23 whehter you use that or the individual components really isn't relevent Mar 16 22:54:35 Ok. I said I can ask nuby questions.) Mar 16 22:55:09 Still confuse some terminologies... ( Mar 16 22:57:17 kergoth: Alright, thanks man for help. I'll get to work, start studying the external-toolchain internals. Don't you mind if I ask some questions about it from time to time here? Mar 16 22:59:01 nope, fine with me. neither meta-external-toolchain nor meta-sourcery really have a mailing list at this point, so irc or emailing the yocto@ list and cc'ing me would be best Mar 16 23:01:17 Ok, thanks man. Mar 16 23:01:59 np. i'm playing around with it here, too, so if i get anywhere i'll let you know Mar 16 23:02:13 not with much urgency of course, just out of curiosity Mar 16 23:03:00 Great, thanks. I'll be in touch here in the IRC. Got irccloud with history caches... Mar 16 23:05:18 np Mar 16 23:10:49 hmm Mar 16 23:12:05 Something new? ) Mar 16 23:32:38 * might also need to blacklist libgfortran: "PNBLACKLIST[libgfortran] = "not building with an external toolchain" and set the default provider as "libgfortran-external.bb" Mar 16 23:36:32 yes, good point **** ENDING LOGGING AT Sat Mar 17 03:00:00 2018