**** BEGIN LOGGING AT Fri Jun 05 02:59:57 2020 Jun 05 07:56:27 Hey guys, i have a weird error message that i don't understand Jun 05 07:56:45 ERROR: Unable to start bitbake server (None) Jun 05 07:56:45 ERROR: Server log for this session (/home/samsi/dev/yocto/var-fslc-yocto/build_x11/bitbake-cookerdaemon.log): Jun 05 07:56:45 --- Starting bitbake server pid 15544 at 2020-06-05 09:35:43.837173 --- Jun 05 07:56:45 ERROR: Unable to parse Var Jun 05 07:56:45 Traceback (most recent call last): Jun 05 07:56:46 File "Var ", line 1, in Jun 05 07:56:48 File "/home/samsi/dev/yocto/var-fslc-yocto/sources/poky/meta/classes/base.bbclass", line 31, in oe_import(d=): Jun 05 07:56:51 for toimport in oe.data.typed_value("OE_IMPORTS", d): Jun 05 07:56:53 > imported = __import__(toimport) Jun 05 07:56:55 inject(toimport.split(".", 1)[0], imported) Jun 05 07:56:57 File "/home/samsi/dev/yocto/var-fslc-yocto/sources/poky/meta/lib/oe/utils.py", line 472, in : Jun 05 07:57:01 Jun 05 07:57:03 >class ImageQAFailed(bb.build.FuncFailed): Jun 05 07:57:05 def __init__(self, description, name=None, logfile=None): Jun 05 07:57:07 bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception AttributeError: module 'bb.build' has no attribute 'FuncFailed' Jun 05 07:57:55 samsi: next time, please use a pastebin and put only the link and a short explanation in here. thanks! Jun 05 07:58:04 samsi: and since when? what did change? Jun 05 07:59:15 Yeah my bad, sorry Jun 05 07:59:51 i was following those instructions: http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_THUD_V1.0_VAR-SOM-MX7 Jun 05 08:00:41 As soon as i executed the bitbake fsl-image-gui command, this error popped up Jun 05 08:02:36 samsi: if i had to guess, then i would say there is some version mismatch hidden in there somewhere. but as this is some custom setup script of variscite, no real idea. Jun 05 08:03:45 It's a parse error in bitbake itself as far as i can tell, so i guess i am using the wrong bitbake version, but i don't know which version they used in the tutorial Jun 05 08:04:40 samsi: nah, if the xml file that the tutorial refers too is properly writted, then it includes a specific poky revision which in turn specifies the bitbake version Jun 05 08:04:56 samsi: so given these instructions, you shouldn't have to care. Jun 05 08:07:41 Oh yeah you're right. It includes a poky folder with bitbake in it. Now i get a different error Jun 05 08:09:06 Sometimes i really question my intelligence. Thanks for the help! Jun 05 08:13:11 Okay, new error message: https://pastebin.com/82xgZVxj Jun 05 08:14:08 Do you know by chance what PATH variable he means? Jun 05 08:16:45 samsi: That PATH looks very strange. Maybe exit and try again in a new shell Jun 05 08:19:40 Sadly no, new shell doesnt't work. My PATH variable with echo $PATH looks completely different than this error Jun 05 08:23:32 samsi: which TAG name did you use ? Jun 05 08:25:09 What's a tag name? Jun 05 08:26:15 samsi: if you followed the instructions in the website you poined out, you should have called 'repo init'... something Jun 05 08:29:36 Ah. I used the one mentioned, refs/tags/thud-fslc-4.14.78-mx7-v1.0, because that uses the newest kernel and is designed to work with my mx7 as far as i can tell Jun 05 08:37:00 samsi: please restart a fresh setup and verify it's working as it does on my side https://pastebin.com/cuBi9mJ3 Jun 05 08:37:18 samsi: happy hacking with Yocto Project ;-) Jun 05 08:41:02 will do. thx Jun 05 09:00:46 hello, I am using Yocto project to build Linux image and SDK toolchain Jun 05 09:01:02 after sourcing the environment script Jun 05 09:01:16 source /opt/poky-atmel/2.5.3/environment-setup-cortexa5hf-neon-poky-linux-gnueabi Jun 05 09:01:30 I can see which C compiler or C++ compiler Jun 05 09:01:44 using echo ${CXX} Jun 05 09:01:52 or echo ${CC} Jun 05 09:02:14 I added mono framework to my SDK in order to build CSHARP applications Jun 05 09:02:33 I want to know what compiler is used with mono ? Jun 05 09:02:48 wich version ? Jun 05 09:03:01 is there a command line like " echo " ? Jun 05 09:03:33 gaston53: mono isn't part of the generic environment, hence cannot be found there. you have to look into the executables provided by the sdk and ask the compiler specifically. Jun 05 09:07:05 mono cortexa5hf-neon 5.12.0.226-r0 /mono-dbg cortexa5hf-neon 5.12.0.226-r0 /mono-dev cortexa5hf-neon 5.12.0.226-r0 /mono-gac cortexa5hf-neon 5.12.0.226-r0 /mono-libs cortexa5hf-neon 5.12.0.226-r0 /mono-libs-4.5 cortexa5hf-neon 5.12.0.226-r0 Jun 05 09:07:27 that are package names. Jun 05 09:07:29 this is what I find in my SDK.manifest file Jun 05 09:07:43 yes Jun 05 09:08:40 so I must check the files generated after the build to see what version of compiler ? Jun 05 09:08:57 well you can also parse bitbke -e..... Jun 05 09:09:10 or use oe-pkgdata-util... Jun 05 09:09:11 or... Jun 05 09:09:59 is there a possibility to use .NET core framework in Yocto project ? Jun 05 09:10:04 without mono Jun 05 09:10:08 yes. Jun 05 09:10:48 how ? because while searching I did not find that .NET core is maintained by Yocto Jun 05 09:11:13 I have to add mono to my image in order to run .net applications Jun 05 09:13:25 gaston53: here is some inspiration to get started https://github.com/intel-iot-devkit/meta-iot-cloud/blob/master/recipes-devtools/dotnet/dotnet_3.0.0.bb Jun 05 09:14:00 gaston53: no idea if there is a halfways properly maintained layer by MS yet, its totally not impossible. but you'll have to go hunting yourself Jun 05 09:15:41 well I just found the meta-mono layer provided by Yocto in order to run .NET apps Jun 05 09:17:33 it all depends. (TM) Jun 05 09:36:00 gaston53: this is the procedure I tested last year https://wiki.yoctoproject.org/wiki/Building_and_running_embedded_Linux_.NET_applications_from_first_principles Jun 05 09:44:57 mckoan well I cloned meta-mono layer, I added it to bblayers.conf file, I added IMAGE_INSTALL_append = " mono" /TOOLCHAIN_TARGET_TASK += "mono-dev" to local.conf and than I run Bitbake core-image-minimal Jun 05 10:15:29 RP, in python, can I easily check wether a variable, or any of its inactive overrides is defined ? Jun 05 10:16:17 (the active overrides I can detect just using d.getVar() and checking for None, I assume) Jun 05 10:34:12 And another question: if I want to execute python code during parsing, is the best way to use inline python and a direct assignment := to a dummy variable, or is there a more proper way ? Jun 05 11:04:36 Hello there, I want to build an image using musl libc but couldn't build wpewebkit package using it. Is there anyway to explicitly specify libc for a single package? Jun 05 11:06:14 ilkmc2r, you could try setting it per recipe, but I doubt anyone has tried that before, sounds like it wouldn't really make sense (?) Jun 05 11:07:00 kroon: How can I do it? By modifying recipe ? Jun 05 11:07:42 I am using enviroment variable for whole build like: TCLIBC=musl bitbake core-image-base Jun 05 11:08:17 ilkmc2r, set it in your local.conf for instance using an override, TCLIBC_pn-wpewebkit = "musl" (if wpewebkit is the recipe name, not package name) Jun 05 11:08:35 dunno if overrides work if set via the environment, maybe try that first Jun 05 11:09:02 s/musl/glibc i suppose Jun 05 11:10:08 thanks kroon, I am trying Jun 05 11:10:54 ilkmc2r: Be careful, TCLIBCAPPEND may change the TMPDIR path based on the libc choice. You may need to set that to an empty string Jun 05 11:11:19 paulbarker, thanks Jun 05 11:11:49 Though in general you wouldn't want to mix libc's in a single tmp directory Jun 05 11:12:18 Give it a go but it's worth knowing you're in "Here be dragons" territory Jun 05 11:17:37 smurray: Thanks your answer made me look into variable scoping in Bitbake and now it makes perfect sense Jun 05 11:24:47 kron I wrote TCLIBC = "musl" TCLIBC_pn-wpewebkit = "glibc" to conf/local.conf but it still trying to compile using musl :( Jun 05 11:28:33 ilkmc2r, is the recipe called "wpewebkit" ? Jun 05 11:30:19 you could check the output of "bitbake -e wpewebkit | grep ^TCLIBC=" to double check that the value is getting propagated Jun 05 11:44:09 kroon: recipe file: ./meta-webkit/recipes-browser/wpewebkit/wpewebkit_2.20.2.bb Jun 05 11:44:22 bitbake -e wpewebkit | grep ^TCLIBC=TCLIBC="musl" Jun 05 11:44:31 bitbake -e wpewebkit | grep ^TCLIBC=TCLIBC="musl" Jun 05 11:50:12 ilkmc2r, I can override it for one of my recipes Jun 05 12:14:15 kroon: I found a patch for wpewebkit for build it with musl, apllied it and now it builds. thanks for your help Jun 05 12:18:30 ilkmc2r, yeah that is probably the most sane way forward Jun 05 12:20:01 If I have a patch URL like https://patchwork.openembedded.org/patch/165264/, how do I reach the enclosing series ? google located this which looks to be a solution to my last build issue, but I'm wary to apply a 4/4 patch without getting the context... Jun 05 12:22:21 yann: I don't know any way to do that but you could guess that if that's 165264 you could try 165261 to 165263 as URLs Jun 05 12:23:18 it would be cool to have backlinks to the series from each patch Jun 05 12:25:16 yann: patchwork.kernel.org has them so if our patchwork instance gets upgraded we should have them. We need someone to volunteer to wrestle patchwork Jun 05 12:25:18 got it searching series by author and date - https://patchwork.openembedded.org/series/20136/ - I'm puzzled that such a series is still NEW, though Jun 05 12:31:16 looking for any ml discussion, google finds the post at https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg128085.html - here too, we have no backlink to the relevant thread index - and the date index only goes back to March '20. What do I miss ? Jun 05 12:31:56 well, it's not true there's no backlink - it does exist but is brken Jun 05 12:32:34 there is an issue with malil-archive.com ? Jun 05 12:35:40 yann: I recommend looking at the archives on lists.openembedded.org Jun 05 12:36:10 i'm on it, but there are no backlinks to threads either :) Jun 05 12:36:49 I'm puzzled that those did not show up on the google search, btw - some SEO issues maybe ? Jun 05 12:42:20 It seems hard to locate any replies, I can't see a thread view anywhere Jun 05 12:43:19 RP: I fixed mcdepends here: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/mc-bbmask&id=a9a596ad95f70b423872a18cbc9d9f7b61ebd744 but I'm not sure if it needs to be reworked to keep the API backward compatible with older siggens. Jun 05 12:58:10 Hello, i tried doing what mckoan did, and i still get this message: https://pastebin.com/nBSPBKqA Jun 05 12:59:08 It's somethin system related so i think it will be fixed if i reinstall the system, which i really don't want to do. Jun 05 13:00:09 samsi: well you can always "escape" into a container Jun 05 13:00:15 samsi: please pastebin even the commands you ran to get there Jun 05 13:00:42 samsi: what kind of host system is thes, even? Jun 05 13:00:45 samsi: What mckoan said. We need the full bitbake output and the command you ran to help any further Jun 05 13:00:57 Never used containers before, but i am willing to learn new stuff :) Jun 05 13:01:06 Will get everything, brb Jun 05 13:01:18 It looks to me like an attempt to run bitbake inside bitbake task Jun 05 13:01:53 That's the only way I can fathom seeing all those entries in the PATH when bitbake starts Jun 05 13:05:17 https://pastebin.com/eeb3sdpA Jun 05 13:05:25 What's bitbake task? Jun 05 13:06:13 as already said this morning, is suspect the combination of that setup magic script and your system to be b0rk3d. Jun 05 13:06:41 plus, you haven't named your host still. Jun 05 13:07:26 erm. Jun 05 13:07:30 Hm, probably. It's a Lenovo Thinkpad Yoga 370 running Zorin OS 15, which is based on Ubuntu 18.04LTS Jun 05 13:07:49 samsi: You shouldn't be using a path to that bitbake script. Just run `bitbake` Jun 05 13:07:50 why a relative path to bitbake, even? Jun 05 13:07:55 paulbarker: hi5 Jun 05 13:08:59 samsi: after you called ./setup-environment build_fb (line 6) you have already been moved into the directory build_fb Jun 05 13:09:00 Because it cannot find the bitbake command, because its not set in PATH Jun 05 13:09:15 samsi: please wait Jun 05 13:09:24 samsi: then, again - the setup script. Jun 05 13:09:26 samsi: 1. close your terminal window Jun 05 13:09:38 samsi: 2. reopen it Jun 05 13:09:38 samsi: Should you be sourcing the setup-enviornment script instead of running it as a separate process? Jun 05 13:09:47 paulbarker: dang you typed faster. Jun 05 13:10:01 paulbarker: was just about to say the same thing. Jun 05 13:10:14 3. go in the yocto directory and launch again the command at line 6 Jun 05 13:10:17 I'd also try a plain build following the Yocto quick start guide to confirm that nothing is majorly broken Jun 05 13:10:32 4. then simply call bitbake core-image-minimal Jun 05 13:10:52 samsi: the guide you linked does it say right, section 4.3 by the way. Jun 05 13:11:16 paulbarker: yep, samsi could give a try at this https://wiki.koansoftware.com/index.php/Yocto_Project_my_own_quick_start Jun 05 13:11:42 * Letothe2nd hereby files this under "only skimming stuff instead of even properly copypasting" then. Jun 05 13:17:16 samsi: did you follow step 1,2,3,4 above? Jun 05 13:18:42 Okay, i tried what mckoan said, clsoed and reopened the terminal for the 100th time, did the command, still the same error. Jun 05 13:19:05 paulbarker: what do you mean by sourcing the setup-environment? Jun 05 13:19:48 Letothe2nd: What am i doing wrong that the guide does right? Jun 05 13:20:29 samsi: look again at 4.3, and look very closely. Jun 05 13:20:43 samsi: hint: "sourcing" is script is not the same as "running" it. Jun 05 13:21:35 samsi: i also second mckoan's suggestion to start out easier and get a basic grasp of the technology first before battling those custom things. Jun 05 13:21:37 Letothe2nd: Oh, you mean the dot and then the setup-environment? I thought that was a typo, because if i try to run it like that it cannot find the setup-environment file Jun 05 13:21:50 samsi: that is not a type. Jun 05 13:21:59 samsi: *typo. Jun 05 13:22:33 samsi: thats what i mean. you silently glossed over things where you deviated from the guide, and we get to do the puzzle. Jun 05 13:22:45 Letothe2nd: Ah well, i fucked up then. My bad. So why is it not finding the setup-environment file? Jun 05 13:23:06 Letothe2nd: And i'm very sorry for that. Apologies Jun 05 13:24:14 samsi: probably because you are in the wrong directory, or something like that. another rason for starting out easier: this is customstuff we do not know. the setup scripts of a generic poky we know pretty well, on the other hand. Jun 05 13:24:26 Tell that to my boss :) He thinks it's a great learning experience Jun 05 13:24:50 samsi: as long as i can also tell your boss my invoice, its fine. otherwise i disagree. Jun 05 13:25:23 Well, i am in the correct directory, the tutorial says so, and the file is in that directory. But yeah, you're right. Jun 05 13:25:30 Letothe2nd: hahahaha Jun 05 13:25:34 samsi: and, make sure you really watch at least the essential parts of https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Jun 05 13:26:26 Yeah, i will definitely do that, still haven't done that, should've done it ages ago. Jun 05 13:26:56 *bingo* Jun 05 13:27:06 instead of assuming others do typos. Jun 05 13:27:27 Assuming isn't a good idea most of the times. Jun 05 13:28:06 Yep. Jun 05 13:28:27 And with that, have fun everybody. $SIGFAMILY. Jun 05 14:05:44 Hello. I've creating a layer that I use to slightly modify final image from my company's BSP. In the layer there's a single recipe called woky-customization.bb that just puts few configuration files into /etc, so there's also some files in files/ directory and the recipe defines SRC_URI = "file://...". Jun 05 14:06:33 and they now conflict with the packages that originally provide those files? Jun 05 14:06:37 However bitbake complains that my recipe doesn't have a LICENSE and when I set it to GPLv2 it then complains I don't have LIC_FILES_CHKSUM. But, I don't really need a license file now. Jun 05 14:07:07 Is there any way to just skip the license check on this recipe? Jun 05 14:08:02 I'm sure handling of licenses is important but you don't usually think about that when you just copy some files to /etc. Jun 05 14:10:21 short term you can set LICENSE="CLOSED" Jun 05 14:10:59 but a fairly common idiom is to declare the license of your files MIT, and then point at the COREBASE/LICENSE file Jun 05 14:11:15 rburton, just googled it, also thank you. :-) I assume that also requires adding LICENSE_FLAGS_WHITELIST += " commercial " which I already have in my local.conf. Jun 05 14:11:21 no Jun 05 14:11:26 that's unrelated Jun 05 14:11:41 Understood, I'll search, thank you. Jun 05 14:12:13 rburton, but what if the codebase does not have a license file? Can I reference some common license file from a base layer? Jun 05 14:12:37 woky_: how do you know what the license is if its not written down anywhere Jun 05 14:13:38 rburton, well, IANAL, but usually in my FLOSS projects I publish on GitHub I just mention that it is GPLv2, without copying license text. Jun 05 14:14:13 well, if its not in the source files then it doesn't count Jun 05 14:14:14 I mention it in a section in README: "This project is relased under GPLv2, go to http://fsf.... " Jun 05 14:14:18 right, there you go Jun 05 14:14:25 thats a license checksum Jun 05 14:14:36 lines 2 through 5 of README, or whatever Jun 05 14:15:08 rburton, oh, I get it, thank you! Jun 05 14:15:17 plenty of examples in oe-core Jun 05 15:46:46 Hello there!I'm looking for crosstool-ng functionality inside Yocto.In other words, I want to build a cross compiler for RPi which will be able to produce code for x86.Did somebody try it before me? Jun 05 15:47:20 the Yocto Project builds it's own toolchains.. It does it differently then the way crosstool-ng works.. Jun 05 15:47:35 You should either use crosstool-ng or use the Yocto Project.. mixing them doesn't make sense Jun 05 15:48:24 That the point, I want to use only Yocto. Jun 05 15:50:46 For just a cross-compiler, you would configure the system with a recipe target of meta-toolchain. Check the Yocto Project documentation for that stuff.. Jun 05 15:51:52 If I build core-image-sato-sdk target. It will install GCC into the target, but it will be a native compiler. I want to have compiler for x86 inside the target device with arm CPU. Jun 05 15:51:59 If you want to replace the RPi OS with a Yocto Project OS that can be done as well. Jun 05 15:52:13 So you want to build x86 from arm? Jun 05 15:52:51 Yes, build for x86 from arm Jun 05 15:55:06 You have two options, install the Yocto Project on your RPi system, and build targeting an x86 system.. or on your x86 host, you should be able to set the SDKMACHINE=aarch64 -- this will produce an SDK that runs on aarch64, but was compiled on your normal x86 host.. Jun 05 15:55:15 whatever taret machine you select will be the target of the SDK. Jun 05 15:56:58 The first option is not acceptable, I will wait a lot of time to wait until it will be done :) Jun 05 15:59:11 The second option requires more details. Because as I see SDKMACHINE specifies where toolchain will run, but not specify target arch. Jun 05 16:29:36 MACHINE is target arch Jun 05 17:04:08 But in my case MACHINE is raspberrypi4-64 Jun 05 18:03:19 zeddii: I have a patch for v5.4/standard/preempt-rt/base to fix a stability issue: https://github.com/gmccollister/linux-yocto/commit/534a2bc523d76d85e9f759580b88a3c6b28335b5 Jun 05 18:08:15 In the past, I've done a "re-apply" of the updated rt-patches on new (yocto derived) baselines as a fast-forward double check ; since it sometimes can shed extra light on what is conflicting in a merge... Jun 05 18:09:32 yeah, I found this one with git bisect after I started experiencing crashing after updating from an old v5.4 version Jun 05 18:10:06 georgem_home, yah - never fun. Hope it didn't eat any filesystems in the process. Jun 05 18:10:46 it didn't but lucky enough we caught it in testing anyway Jun 05 18:12:25 I'm about to do some kernel merges for trouble that paulg is sending me, so if you fire a patch to the linux-yocto mailing list, I can pick it up quickly. I'm also doing another -rt -stable update shortly, but that won't cause an issue. Jun 05 18:13:00 ok. somehow I missed there was even a linux-yocto mailing list. I'm on all the others. I'll go join. Jun 05 18:15:16 georgem_home, it is where I dump all the v5.2.x updates. Jun 05 18:15:21 https://lists.yoctoproject.org/g/linux-yocto/message/8728 Jun 05 18:17:26 cool Jun 05 18:22:15 in hindsight, I kinda wish it had got a different name that reflected better that the list was meant for kernel content, but that ship sailed years ago.... Jun 05 18:29:26 Yeah here https://www.yoctoproject.org/community/mailing-lists/ it says "Discussion list for the linux-yocto layer" which is a bit confusing since AFAIK it's only a recipe/kernel repo not a layer. Jun 05 18:30:05 it probably should say "repository" instead of "layer".... at a minimum. Jun 05 18:30:28 yeah Jun 05 18:31:04 anyway, patch sent to ML Jun 05 18:31:16 even that isn't perfect ; if you are new to yocto, you wont necessarily xlate that to http://git.yoctoproject.org/cgit.cgi/linux-yocto/ Jun 05 18:32:12 if nothing else, at least in theory, a few more lurkers here are now aware of it. :) Jun 05 18:33:20 hehe Jun 05 18:44:22 Is there a way to publish a kernel config file into the images directory without a custom do_deploy_append()? Jun 05 18:55:52 rewitt, will CONFIG_IKCONFIG (or whatever it is called) that creates /proc/config.gz on target do what you need? Jun 05 18:57:28 paulg, they actually want it as part of the build artifacts. My guess is they won't like me telling them to boot kvm and harvest it :) Jun 05 19:00:38 paulg, Oh do you mean to extract it from the kernel image itself? That's not a bad idea, but would still require the scripts to run on the kernel in the images directory. Jun 05 19:04:55 rewitt, the /proc/config.gz is definitely a solution that involves booting, but it should be relatively simple to copy it from tmp/work/..../linux-yocto/.../.config to whereever you want with a trivial bbappend. Jun 05 19:05:39 paulg, Yeah that's what was recommended, but I wanted to double check before adding more items. Thanks. Jun 05 19:06:11 np Jun 05 19:14:01 some distros copy the kernel config file into /boot ; could be something that yocto might consider as well (?) Jun 05 19:28:50 paulg, They do that as part of the kernel-dev package Jun 05 19:32:20 rewitt, could be - I didn't go actively searching out what is currently done ; I was assuming you'd already done that. ;-) Jun 05 20:46:36 Hello, I am trying to add the "ifstat" tool to my image, so far I have this receipe: Jun 05 20:46:41 DESCRIPTION = "Ifstat"LICENSE = "MIT"LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b"SRC_URI = "http://gael.roualland.free.fr/ifstat/ifstat-${PV}.tar.gz"SRC_URI[sha256sum] = "8599063b7c398f9cfef7a9ec699659b25b1c14d2bc0f535aed05ce32b7d9f507"inherit autotools Jun 05 20:47:27 But I have this error: Jun 05 20:47:28 ERROR: ifstat-1.1-r0 do_compile: oe_runmake failedERROR: ifstat-1.1-r0 do_compile: Function failed: do_compile (log file is located at /opt/workspace/build/tmp/work/aarch64-poky-linux/ifstat/1.1-r0/temp/log.do_compile.9975)ERROR: Logfile of failure stored in: /opt/workspace/build/tmp/work/aarch64-poky-linux/ifstat/1.1-r0/temp/log.do_compile.9975Log Jun 05 20:47:28 data follows:| DEBUG: SITE files ['endian-little', 'bit-64', 'arm-common', 'arm-64', 'common-linux', 'common-glibc', 'aarch64-linux', 'common']| DEBUG: Executing shell function do_compile| NOTE: make -j 12| make: *** No rule to make target 'Makefile.in', needed by 'Makefile'. Stop.| ERROR: oe_runmake failed| WARNING: exit code 1 from a shell Jun 05 20:47:29 command.| ERROR: Function failed: do_compile (log file is located at /opt/workspace/build/tmp/work/aarch64-poky-linux/ifstat/1.1-r0/temp/log.do_compile.9975)ERROR: Task (/opt/workspace/meta-seasam/recipes-support/ifstat/ifstat_1.1.bb:do_compile) failed with exit code '1' Jun 05 20:48:01 when I build locally on my computer, it builds correctly. The configure step returns the exact same output Jun 05 20:48:54 any advice ? Jun 05 21:24:02 JPEW: I see what you mean about compatibility, hmm :/ Jun 05 21:25:34 JPEW: did you need an OE-Core patch too? Jun 05 21:26:10 yes, next patch :) Jun 05 21:53:29 o/ Jun 05 21:54:03 Hi guys, I'm trying to build coreutils for mingw32 as part of a Windows SDK for an embedded Linux product Jun 05 21:54:18 RP: Ya, making it compatible would be a pain Jun 05 21:55:17 I removed the dependency on libcap from the coreutils recipe, but it looks like it is trying to build for Linux instead of for mingw32 Jun 05 21:55:48 Not only because the function is passing a dict of datacaches instead od a single one, but also because the rundep_check() function will now be called for all mcdeps, where as before they were filtered out Jun 05 21:55:49 Has anyone been able to build coreutils for Windows before, or encountered issues that sound like what I'm seeing? Jun 05 21:56:54 easwarh: I don't know if anyone has built coreutils-nativesdk for Windows before Jun 05 21:57:35 easwarh: I don't see any bbappends in meta-mingw, so probably the answer is no :) Jun 05 22:00:40 JPEW: ouch. I figured it would be simple because Cygwin, as I understand is it based on mingw32 and provides coreutils.. Jun 05 22:01:02 JPEW: In fact, this stackoverflow describes exactly the error I'm seeing: https://stackoverflow.com/questions/7039728/mingw-errors-while-building-coreutils-consistent-errors-on-both-windows-and-lin Jun 05 22:01:20 JPEW: really not sure how we handle this. Will think on it Jun 05 22:01:28 easwarh: Cygwin is uses MinGW, but it's different Jun 05 22:01:48 RP: That's fine. We *can* make it compatible, but it will be messy and tricky to get just right Jun 05 22:02:00 JPEW: might have to set a variable to determine which format the data is in maybe? Jun 05 22:02:07 RP: Ya maybe Jun 05 22:02:18 That would make it less messy Jun 05 22:02:48 easwarh: Cygwin provides a compatibility layer that translates POSIX API to the underlying Windows API Jun 05 22:03:35 easwarh: MinGW does not. If a program compiles for Windows MinGW, it uses the Windows API. Jun 05 22:04:37 JPEW: Does that mean that a program compiling for Windows MinGW needs to be aware of the differences between Windows and POSIX APIs? Jun 05 22:04:50 easwarh: Correct Jun 05 22:05:11 MinGW is a more "native" approach than Cygwin Jun 05 22:06:41 JPEW: Interesting, thanks! Jun 05 22:13:13 Erg, why can't I run oe-selftest -r bblayers.... **** ENDING LOGGING AT Sat Jun 06 02:59:57 2020