**** BEGIN LOGGING AT Wed Jun 07 03:00:04 2017 Jun 07 05:43:35 RP: I could start working on BBFILES_DYNAMIC now. Please let me know if you have already something. Jun 07 06:14:44 morning all Jun 07 06:39:33 Good morning Jun 07 06:40:21 I was wondering if there is a way to run "make scripts" in the /usr/src/kernel folder within a recipe Jun 07 06:59:03 Hello everyone, when I executed do_install task for sed (current master branch, using submodule gnulib), bring in many errors: "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored" Jun 07 07:05:21 my host was ubuntu16.04 x86-64, I bitbake pseudo-native, the libpseudo.so under ../recipe-sysroot-native/usr/lib/pseudo/lib64/libpseudo.so Jun 07 07:07:36 pohly: I have something I've not tested yet Jun 07 07:09:56 RP: I can test it for you, if you want. Jun 07 07:14:43 pohly: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=f12845d1346e2d2260e109ca0f26ddc18b8863d9 Jun 07 07:14:51 RP: thanks Jun 07 07:15:02 pohly: it at least tells you where in the code we might want to add this... Jun 07 07:35:32 Hi, is possible to disable a daemon startup using a bbappend file? For example, I want to install nfsd package in my image but I don't want that start at boottime... Jun 07 07:36:53 teo_icKs: it certainly should be, just look up how the daemon is started, find where that is set up in the recipe, and then modify that through the append Jun 07 07:47:04 LetoThe2nd: ok thanks... I try to search... so it doesn't exist a variable or a well known way to do this...is it true? Jun 07 07:49:00 teo_icKs: it just depends on the particular daemon. and on your init system Jun 07 07:53:21 teo_icKs: taking a very quick glance, it looks like for systemd (if you're using it) it should be enough to just set SYSTEMD_AUTO_ENABLE = "disable" in your append (see also https://github.com/openembedded/openembedded-core/blob/master/meta/classes/systemd.bbclass) Jun 07 07:57:08 LetoThe2nd: ohhh cool... that's exactly what I want but unfortunatly I'm using SystemV / nfsd... so I try to search in update-rc.d.bbclass... Jun 07 08:00:16 teo_icKs: thats why i said, it depends. :) Jun 07 08:02:14 LetoThe2nd: :) ok thanks.... Jun 07 08:08:13 RP: I had (mentally, no actual code) at a similar solution to yours. Jun 07 08:08:20 It is working fine here now. Jun 07 08:10:03 I made some more changes (off-by-one-error in the split(), hard error for invalid entries, slightly different wording in the error message). I can submit a patch mentioning your original work in the commit message, if that's okay with you. Jun 07 08:22:31 pohly: sounds great, thanks! Jun 07 08:34:50 Curiously... if I build a system with yocto, will the output contain setuid binaries ? Jun 07 08:35:26 And, while building, will the regular user own the said setuid binaries which are eventually placed into a rootfs ? Jun 07 08:38:45 RP: may collection names contain slashes? Jun 07 08:38:48 gtristan: yes, there will likely be setuid binaries Jun 07 08:39:14 pohly: since collection names are used in variable names, perhaps not? Jun 07 08:39:23 gtristan: they will likely not be suid for the build user, though, because permissions are emulated during a yocto build using pseudo Jun 07 08:39:26 There is a documentation to explain how gstreamer use the memory through the pipeline process ? Thx. Jun 07 08:39:35 I'm worried that invalid BBFILES_DYNAMIC entries like ${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend:core will silently be ignored with the code as it stands. Jun 07 08:39:59 ChrysDaze: that sounds like a gstreamer question and is probably best asked in a gstreamer-specific channel? Jun 07 08:40:01 pohly: don't you have that backwards (layername should be first?) Jun 07 08:40:12 RP: exactly ;-) Jun 07 08:40:17 That's the error. Jun 07 08:40:23 pohly: oh, right :) Jun 07 08:40:27 I.e. the error that was made by the developer. Jun 07 08:40:35 neverpanic : yes sure Jun 07 08:40:53 If the collection name isn't allowed to contain slashes, then detecting the error would be possible. Jun 07 08:41:30 pohly: hmm, '/' is a valid char according to the regexp Jun 07 08:41:41 pohly: * is not though Jun 07 08:42:02 pohly: (see ConfHandler.py) Jun 07 08:42:03 Well, I guess than we have to rely on devs to not make such a mistake Jun 07 08:42:14 __config_regexp__ Jun 07 08:43:04 neverpanic, aha I see, I'll have a look into how that works thanks :) Jun 07 08:45:40 gtristan: http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/ Jun 07 08:46:22 gtristan: in a nutshell, its a LD_PRELOAD library that emulates being root and writes the permissions into an SQLite database rather than to the filesystem (for the most part, some things are written to both SQLite and the filesystem) Jun 07 08:47:00 gtristan: when things are packaged into archives later on, that runs under the same emulation, faking the permissions tar(1) reads. Jun 07 08:49:35 neverpanic, I see, so you get cooperation on both sides, the sandboxing and the storage Jun 07 08:50:40 neverpanic, I'm trying to do similar using ostree as a backend and bubblewrap (unprivileged namespace) as build sandbox, right now I'm considering if it's really worth the extra trouble just to avoid the case of the user owning an suid binary which is intended to end up in a rootfs Jun 07 08:50:54 s/as a backend/as storage/ Jun 07 08:52:18 in any case, we already dont support static dev nodes or assignment of arbitrary (non-root) uids, just the setuid binaries seem to be trouble Jun 07 08:54:13 gtristan: pseudo is pretty cool and should work standalone in its own right fwiw Jun 07 09:07:14 Any recommended guide for getting started with smart? Jun 07 09:07:52 RP, myeah sounds interesting; I wonder though if an LD_PRELOAD is the right fit... seems like it would be nice to have that functionality as a fuse mount Jun 07 09:08:18 but maybe that's impossible and I'm just having wild ideas :) Jun 07 09:08:30 gtristan: Alternatively you could just go for a real user namespace, I guess? But that also has its downsides. Jun 07 09:08:42 neverpanic, I am Jun 07 09:09:42 neverpanic, using setuid installed bubblewrap we create an unprivileged namespace, and we have some normal limitations (no creation of static dev nodes or assignment to arbitrary uids), but then if we create suid binaries; they are really on the filesys Jun 07 09:09:48 Oh right, misunderstood the README of bubblewrap Jun 07 09:09:52 so it's a bit of a security concern Jun 07 09:10:13 if I build a system with /usr/bin/sudo, it means other users can gain my builder user's privileges Jun 07 09:12:23 personally I feel like it's not really a huge deal, but maybe I'm overly nonchalant about this suid thing Jun 07 10:10:06 huh well something broke mut well Jun 07 10:20:52 Do I just copy /var/lib/smart/config to keep my smart config after an upgrade? Jun 07 10:37:31 rburton: hey, so for meson support, I'd need latest & greatest yocto i guess? Jun 07 10:39:49 zeenix: the recipes are in meta-oe right now, but you might want to grab the latest copy and apply the patches that are on the list... Jun 07 10:40:26 rburton: ok, thanks Jun 07 10:41:46 whoop whoop meson \o/ Jun 07 10:41:59 should finish porting the GUnP* things Jun 07 10:42:59 zeenix: g-i doesnt work for me right now, haven't got around to looking why yet Jun 07 10:43:21 we need to bring it into oe-core so i do care about getting that fixed Jun 07 10:45:25 understood Jun 07 10:47:27 zeenix: my WIP pieces are poky-contrib:ross/meson for recipe enabling and some hacks, and meta-oe-contrib:ross/meson for my own recipe changes. there's a series of patches on the list by another guy that conflict though. Jun 07 10:47:43 no doubt you understand GI more than me so feel free to fix up json-glib :) Jun 07 10:47:54 rburton: i'm not in any hurry at all so it's ok Jun 07 10:48:32 currently i just want to know the status of meson in yocto cause I intend to do a short intro presentation of meson at our office and yocto is going to be the first question of course :) Jun 07 10:54:55 classes and recipe exist, not all features work yet Jun 07 10:55:04 basic stuff works, gi and gtk-doc break it Jun 07 11:05:11 thanks Jun 07 11:11:20 Hi ed2. I'm experimenting with wic using a wks file including sdimage-bootpart.wks and creating an additional partition. I've noticed a couple of issues that I'd like to report. Jun 07 11:17:37 1) the "sdimage-bootpart.wks" http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks/sdimage-bootpart.wks specifies "mmcblk" as the value of the ondisk parameter. While the value is actually not used in the direct.py http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/imager/direct.py#n130 because / and /boot mount points are skipped, it would be wrong for another partition, Jun 07 11:17:39 because it is missing the device number (e.g. "mmcblk0") Jun 07 11:18:58 diego_r: hi Jun 07 11:19:39 hi ed2 Jun 07 11:20:34 diego_r: there is some code in direct.py that looks like it handles mmcblk partition naming. Jun 07 11:20:50 diego_r: this one: prefix = 'p' if part.disk.startswith('mmcblk') else '' Jun 07 11:21:23 diego_r: i'll not be surprised if it doesn't work though. Jun 07 11:21:36 to expand on the above, using "--ondisk mmcblk" you get "/dev/mmcblkpN " instead of ""/dev/mmcblk0pN " Jun 07 11:21:40 mind the missing 0 Jun 07 11:22:07 because "part.disk" is taken as is Jun 07 11:22:36 I mean you get in fstab... Jun 07 11:22:38 yep. makes sense. So, there should be mmcblk0 used in .wks file Jun 07 11:23:18 that's what I think yes. I can send a patch if you agree Jun 07 11:23:46 i was thinking about reomving —ondisk option from canned .wks files. Most of them use max 2 partitions, so —ondisk is not used. Jun 07 11:24:44 diego_r: I'd prefer removing —ondisk. If you can test it and send a patch it would be great. Jun 07 11:25:43 diego_r: that would make it more generic. I don't think using mmcblk or mmcblk0 was a good idea. It's too hardware specific to my taste. Jun 07 11:25:53 Is there any way I can tell recipetool that I want to create a recipe for python3? Jun 07 11:26:08 When I point to a file on PyPi it generates a recipe for python2 Jun 07 11:28:04 ed2: so the ondisk parameter is unused in the case of "/" and "/boot" parameters by current implementation? Jun 07 11:28:33 well, mountpoints rather then parameters Jun 07 11:29:20 diego_r: they're not used, true. and the parameter is optional in .wks Jun 07 11:33:02 diego_r: which hardware do you use, btw? Jun 07 11:35:29 ed2: I'm all surrounded by hardware :-) Right now Boundary Devices Nitrogen6x Jun 07 11:37:20 ed2: so should i remove the "--ondisk" parameter in any line having "/" or "/boot" as mountpoint in any canned-wks? Jun 07 11:38:31 diego_r: you can try :) Jun 07 11:40:29 diego_r: from my point of view canned wks files should be as generic as possible. All hardware-specific .wks should be placed into /wic/. Jun 07 11:40:51 diego_r: you can see examples in meta-yocto-bsp/wic Jun 07 11:43:19 diego_r: oops, meta-yocto-bsp/wic/beaglebone.wks also contains mmcblk :) It makes sense to change it to mmcblk0. It's not used there, but still it's good to somehow show what to use for extra partitions. Jun 07 11:46:31 ed2: "you can try :)" means someone might not agree? Jun 07 11:47:19 diego_r: there is always a possibility that someone doesn't like some change. That's why we're sending patches for review. Jun 07 11:49:23 diego_r: if you run oe-selftest -r wic(better on qemux86_64 machine) and all tests pass it would be good. Jun 07 11:49:34 ed2: I know, I was just unsure what you meant with that Jun 07 11:50:24 diego_r: well, i meant I'm not sure all people like it, but it worth trying anyway. Jun 07 11:51:48 ed2: but at least you'll have a nice word for my patch :-) Jun 07 11:51:49 kanavin: ping concerning ML Jun 07 11:52:10 LetoThe2nd: pong Jun 07 11:52:25 kanavin: got a second off channel? Jun 07 11:52:29 sure Jun 07 11:53:41 diego_r: sure. you can count on +1 from me Jun 07 11:56:45 good morning all the people Jun 07 12:01:45 currently i just want to know the status of meson in yocto cause I intend to do a short intro presentation of meson at our office and yocto is going to be the first question of course :) Jun 07 12:01:54 errr.. Jun 07 12:02:10 wrong window :( Jun 07 12:07:57 Hey all. I encountered an warning when i'm using the eclipse plugin for autotools development that arm-poky-linux-gnueabi-mt and ...-dlltool is missing, this makes debugging the application in eclipse complicated because the values for the variables are not shown in eclipse directly. Jun 07 12:08:22 i'm using eclipse mars and yocto 2.2.1 Jun 07 12:08:37 has anybody an idea how to solve this problem? Jun 07 12:09:42 debugging the src code as a local application without using the autotools project template is working as expected, from my knowledge eclipse is using the ...-mt tool for debugging Jun 07 12:36:52 What is the philosophy inside layers creation? I mean, if somebody do a layer... like meta-openembeeded / meta-qt5 and so on... when they put a branch like pyro. Is there a kind of line which they have to follow to be everyone compatible between them? Jun 07 12:46:46 migration from krogoth to pyro, crossfingered Jun 07 12:46:51 morty* Jun 07 13:13:33 ed2: did you see patchtest about your uboot patch? :) Jun 07 13:14:29 rburton: now I see it :) Jun 07 13:23:26 rburton: sent v3. will see what I did wrong this time :) Jun 07 13:23:29 cheers Jun 07 13:25:37 rburton: oops, wrong status. sent v4 :( Jun 07 13:26:43 now for a really picky review, lets see if we can get to v7 Jun 07 13:27:33 rburton: the atmel hlcdc patch series for the kernel went to v9 or v10, iirc Jun 07 13:28:52 i think my record is 7 Jun 07 13:30:39 rburton: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/293242.html Jun 07 14:55:02 Hi, I'm having some sdk issues whit my sdk. when I'm building a qt application it complains about Fatal error: invalid -march= option: `armv7-a' Jun 07 15:24:55 So it looks like having system perl 5.26 breaks anything using automake in morty? Anyone aware if there is a patch somewhere? Jun 07 15:28:45 oe-core 7fa044e799db651d45e4732e2527acfc2bc7cd47? Jun 07 15:33:18 rburton: applying that to morty looks like it's working for me. Jun 07 15:33:58 jmesmon: can you send a patch to the list? Jun 07 15:40:35 rburton: done. Jun 07 15:42:45 hello, I'm wondering if anyone can help me with something simple. I noticed that in the oe-core layer, there are two versions of gettext, 0.16.1 and 0.19.6. Is there a way to decide which one makes it into my target build? Should I use a bbmask? Jun 07 15:43:44 twall: in the absence of PREFERRED_VERSION or DEFAULT_PREFERENCE, and assuming both versions are in the same layer, which they are, the higher version will be used Jun 07 15:43:50 twall: see the yocto proejt documentation on those variables Jun 07 15:43:56 thank you Jun 07 15:44:06 twall: unless specified otherwise, newer version is used. there are both because new gettext is GPL3 and you can blacklist GPL3 components, so the old GPL2 version is provided as an alternative. (in the latest release, the old gplv2 versions are in meta-gplv2 instead of oe-core itself) Jun 07 15:44:08 twall: you would never want gettext 0.16.1 unless you're doing a non-gplv3 build Jun 07 15:45:13 kergoth: yeah, I downloaded this layer setup from TI, so there are definitely some uncertainties. Thank you! Jun 07 16:29:07 Hi everyone Jun 07 16:30:08 anyone already integrated python-scipy / python-sklearn into yocto? Jun 07 16:42:08 scipy is painful Jun 07 16:42:27 I don't know of any success stories there Jun 07 16:51:37 i added a DEPENDS += "git-native" to my recipe that uses cmake, but cmake still complains that it can't find git. any ideas? Jun 07 16:56:41 this is weird Jun 07 16:56:41 with open(donefile, 'wb') as cachefile: Jun 07 16:56:42 checksums = pickle.load(cachefile) Jun 07 16:56:49 Exception: io.UnsupportedOperation: read Jun 07 16:56:56 how can a file i just opened not have a read method? Jun 07 16:58:54 'wb' shouldn't that be 'rb'? Jun 07 16:59:19 thanks, i'm blind Jun 07 16:59:23 copy/paste error Jun 07 16:59:24 :) Jun 07 16:59:38 lol, happens to all of us Jun 07 17:09:33 fray: how are you guys figuring out which sources to include in which source/downloads layer, particularly in the case where appends are modifying SRC_URI? Jun 07 17:09:49 i was thinking of using variable tracking to map it Jun 07 17:10:13 we have regular builds (think universe) that run fetchall with a combination of layer configurations.. Jun 07 17:10:36 ah, so it compares the downloaded sources after the builds to see what was added by what? Jun 07 17:10:39 we also have a simple class that helped see the dwonload layers the 'first time'.. after that, it's the responsibility of someone merging the code to make sure any new srcs are there.. Jun 07 17:10:56 * fray looks if the class I'm netioning is still there.. Jun 07 17:11:38 https://github.com/WindRiver-Labs/wr-base/blob/WRLINUX_9_BASE/classes/wr-dl.bbclass Jun 07 17:11:47 I've not used it in a while.. but I assume it still works Jun 07 17:11:52 we don't have download layers, but we do ship installers, some of which are a baseline release and others are added on, and the tool we use is like a package manager, so can't have file conflicts between installer artifacts, so need to have clear areas of responsibility, know what belongs to what Jun 07 17:11:56 this segments the DL dir stuff by layer Jun 07 17:12:28 kergoth, sounds like the requirements our old installer had.. (was a PoS).. which is why the new git based setup was created.. Jun 07 17:13:57 for custom work and stuff, we've got custom layers that either include the associaed DL content or an associated dwonload layer (recommended by the main layer) Jun 07 17:14:09 i'm actually adding git based handling within the installer, so it ships repository content (techincally git pack files) and then manifests are included to set up the checkouts for each based on what manifest is selected (what product version / machine / etc), which works pretty well and avoids any conflicts, but now i have to let releases coexist for sources, which is a bit uglier Jun 07 17:14:13 * kergoth nods Jun 07 17:14:50 well hopefully we'll get parts of the setup program merged into bitbake in the next month or so and we all can void that mess.. Jun 07 17:14:58 the setup program itself handles that using 'mirror-indexes'.. Jun 07 17:15:13 https://github.com/WindRiver-Labs/mirror-index Jun 07 17:15:28 thats the one for the open source version of WRLinux 9. basically it's a dump (munged a bit) of our internal layer index Jun 07 17:15:44 the wr-lx-setup that I published a while back on github supports all of this automatically.. Jun 07 17:16:08 (additional content that we ship simply has it's own mirror-index that can overwrite or augment the ones in the main set) Jun 07 17:16:41 (you can also go from the mirror-index and instantiate a real layer index yourself as well.... havn't really documented that, but it works surprisingly well) Jun 07 17:17:22 sadly not in a position where i can change what install mechanism we use, so can't switch to a layier index approach even if i wanted to, have to roll with it Jun 07 17:18:06 aside: the fact that DL_DIR is one honking big single namespace is just stupid. too easy to get basename conflicts betwen recipes, using downloadfilename is a hack. we should really organize it by recipe, or better yet name the files by checksum and grab and name them at unpack time Jun 07 17:20:12 kergoth that class I pasted before effectively moves the namespace to the collection Jun 07 17:20:44 yeah, we have a similar class, though currently it goes by recipe location, so things get a little fuzzy when multiple layers are bbappending to add/modify sources Jun 07 17:22:23 yup.. with the dependency processing.. we can generate a set of layers so we can build of the DL_DIR (using that class) dynamically.. Jun 07 17:22:49 -c fetchall -k universe is 'interesting'.. (we make use of blacklit/whitelist as well to help control it) Jun 07 17:37:23 https://www.irccloud.com/pastebin/mwfgPVZm/ Jun 07 17:37:35 i added a DEPENDS += "git-native" Jun 07 17:37:41 but doesn't seem to make a difference Jun 07 17:37:47 how do i debug this? Jun 07 17:51:45 is there a way to tell where it's searching? it should be searching within the build sysroot, right? Jun 07 17:51:51 instead of the target sysroot? Jun 07 18:08:33 ah. so git-native is added to ASSUME_PROVIDED Jun 07 18:08:49 but, the cmake toolchain file provided sets "set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )" Jun 07 18:08:56 so it won't ever look in /usr/bin/ for git Jun 07 18:09:00 is this by design? Jun 07 18:10:40 can i just remove git-native from assume_provided? is there a way to do this for just a particular recipe? Jun 07 18:46:35 Hey folks, I'm looking at some brokenness in gcc 6.2 & wondering if it would make sense to just update morty to gcc 6.3 (to avoid backporting individual fixes). Jun 07 18:48:01 I was under the impression that gcc upstream had adjusted their version numbering starting with ~5 so that 6.2->6.3 should corrspond to something like what 4.9.5->4.9.6 was in the past. Jun 07 19:08:02 jmesmon: Hi, could you elaborate the brokenness you have with gcc 6.2? I have an issue in protobuf-c with linaro gcc 6.2 I wonder if you encounter that one Jun 07 19:26:18 maudat: My specific issue is that gcc 6.2 doesn't build with gcc 7. I've submitted a PR to oe-core/morty to backport the fix a few minutes ago. Jun 07 19:26:48 I'm just concerned about things that aren't causing gcc 6.2 to fail to build but should be still be fixed. Jun 07 19:32:53 what is the "proper" way to build and include git-native such that it makes it into the sysroot? i removed it from ASSUME_PROVIDED bitbake.conf and the build failed in a mess of dependency errors Jun 07 19:34:12 i'm not entirely surprised Jun 07 19:34:25 presumbaly you need a git-native because your host git is really old? Jun 07 19:34:38 if so that's what the buildtools-tarball is for Jun 07 19:35:58 miceopede: bitbake needs git at parse time, long before anything is built, including git-native Jun 07 19:36:30 i see. is there a way to get my host git into the sysroot? Jun 07 19:36:37 my problem is that cmake's FindGit() can't find it Jun 07 19:36:45 because it doesn't search the system paths Jun 07 19:36:59 ah, so that's an entirely different problem Jun 07 19:37:24 one fix is to set OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH" in your recipe Jun 07 19:37:35 rburton: OE's cmake toolchain removes the system search paths from the find_* paths, for good reason Jun 07 19:37:40 yes Jun 07 19:37:52 and setting that variable is the workaround Jun 07 19:38:02 if i set it to BOTH, though, it may incorrectly find headers and other libraries in there, right? Jun 07 19:38:04 or, patch out the check if its pointless for the build Jun 07 19:38:19 its _PROGRAM so hopefully not but who knows, yay cmake Jun 07 19:38:26 wonderful :D Jun 07 19:38:33 i think i'll patch it out, just to be safe Jun 07 19:38:35 thanks. Jun 07 19:38:40 probably easier :) Jun 07 19:38:48 demanding git to be present to build seems a bit overzealous Jun 07 19:39:09 i've found several pacakges that demand python headers to be present because they want a python binary during the build Jun 07 19:39:12 not my code, but they use it to embed git log and hash information into the binary Jun 07 19:39:29 yeah patch it out and just set the path to "git" :) Jun 07 19:39:40 autoconf lets you pass the value for tests like this Jun 07 19:40:03 so you'll see recipes setting eg ac_cv_PROG_GIT to seed the location of the git binary, to stop autoconf looking on its own Jun 07 19:40:36 rburton: perfect. thanks so much! Jun 07 19:41:38 does anyone know what to do to resolve this error: /usr/lib64/libsnappy.so: undefined reference to `std::__cxx11::basic_string, std::allocator >::resize(unsigned long, char)@GLIBCXX_3.4.21' ? I'm on F26 now, but I was getting the same error on F25. Jun 07 19:42:14 nemequ: you haven't told us what exactly is failing Jun 07 19:42:36 no target recipes should be linking against that lib, so presumably it's running a tool from a native recipe Jun 07 19:42:52 sounds like you're using sstate that was built on a newer host than you're building on now Jun 07 19:43:04 kergoth, `bitbake core-image-minimal` -> https://pastebin.com/YzTrs7mT Jun 07 19:43:16 kergoth, nope, completely fresh checkout. Jun 07 19:43:38 sounds like something wrong on the host, then Jun 07 19:43:42 quite odd Jun 07 19:43:54 kergoth, totally fresh f26 install, too Jun 07 19:44:31 i was hoping upgrading from f25 to f26 would fix the issue so i installed it, same error i was getting on f25 Jun 07 19:45:02 nemequ: disable uninative Jun 07 19:45:47 khem, how do i do that? Jun 07 19:47:03 the issue is probably due to _GLIBCXX_USE_CXX11_ABI has different value for your host libstdc++ Jun 07 19:47:15 and one expected by uninative Jun 07 19:47:39 khem, yeah, i saw that, but adding -D_GLIBCXX_USE_CXX11_ABI=0 to all the cflags/cxxflags i could find didn't help Jun 07 19:47:56 tried =1, too Jun 07 19:48:15 google isn't helping me figure out how to disable uninative… Jun 07 19:59:38 I'm currently using yocto to build an arm toolchain, which I can use to build my application (outside of yocto) for the targeted hardware. Can I use yocto to also genereate an x86 toolchain to build a version of the application to run locally? Jun 07 20:01:59 nemequ: in meta-poky/conf/distro/poky.conf comment out INHERIT += "uninative" Jun 07 20:02:43 rschaefe: the SDK does not include native gcc until 2.3 release Jun 07 20:03:14 rschaefe: what you can do is build an SDK for qemux86-64 Jun 07 20:03:18 and use that toolchain Jun 07 20:05:54 2.3 is pyro correct? I tried to move to pyro but ran into some bitbake issues. Jun 07 20:06:05 yeah Jun 07 20:06:46 Thanks. So the idea is to build for a new machine, with the same image -c populate_sdk? Jun 07 20:07:43 yeah Jun 07 20:41:17 khem, it didn't work. sorry about the delay, wanted to try a fresh build… Jun 07 20:42:37 the build did seem to take longer, so i'm guessing commenting that out worked, but i still see the same error Jun 07 20:52:48 hi folks, is there a "right way" to handle a kernel module that installs some userspace (uapi) headers? I've noticed that having the kernel module install them causes some annoying dependency chains from the kernel into userspace (and my kernel seems to rebuild itself more than actually needed) **** ENDING LOGGING AT Thu Jun 08 03:00:01 2017