**** BEGIN LOGGING AT Mon Dec 14 02:59:58 2015 Dec 14 08:05:01 Hi, why is the GNU Make version used by yocto in bitbake builds different from the one packaged into SDK? Dec 14 08:08:49 mcfrisk: that doesn't sound right to me Dec 14 08:09:46 bluelightning: make 3.81 is selected from poky meta, but 4.0 is skipped (what ever that means) Dec 14 08:10:43 mcfrisk: there Dec 14 08:10:45 argh Dec 14 08:11:09 mcfrisk: there's nothing out of the box that would make that happen - perhaps you have some kind of blacklisting or similar configured? Dec 14 08:11:51 hmm, gplv3? Dec 14 08:13:15 yep, seems like that gplv3 is somehow involved. Dec 14 08:14:25 and funnily make_3.81 doesn't have nativesdk stuff, but 4.0 does.. Dec 14 08:16:30 I'm having this weird issue with TI SDK 2 and QtCreator debugging, when I place a breakpoint when the debug session has started the application stops, when placing it before the session starts it works fine. Debugger log in QtCreator reports: BREAKPOINTS ARE NOT FULLY SYNCHRONIZED Dec 14 08:16:36 Exactly like this: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/467506/1699296#1699296 Dec 14 08:16:48 Any thoughts what could be the issue? Dec 14 08:39:26 hmm. make 3.81 vs. 4.0 selection was a GPLv3 filtering problem which I can fix easily. But builds are not picking the 4.0 version up. Does sstate cache know about make version? Dec 14 08:47:02 mcfrisk: it won't be sstate-related... if it's not building it then it's still being prevented by something in the configuration Dec 14 08:48:12 it is building, right version of make is selected when building make. But not when building other packages e.g. busybox. Dec 14 08:48:34 feels like the old version is pulled from sstate cache or something. Even after wiping tmp. Dec 14 08:49:08 PR pumb of make does not help either. Dec 14 08:49:10 hmm Dec 14 08:50:43 the make update should basically invalidate whole sstate cache since everything depends make, but it does not. Dec 14 09:30:25 Hey all. I've tried googling, but I cant find anything about BLAS libraries on Yocto. Is there any reason I cant find recipies? Dec 14 10:02:55 good morning Dec 14 10:23:12 Hi there. After upgrading to Yocto 1.8.1, autotools returns 1 for all warnings. Adding -Wall does not change this. It makes a recipe fail, which is actually working, also with earlier versions of Yocto. How can I force autotools/autoreconf to return 0 for all warnings? Dec 14 10:31:06 how to force rebuild of make-native when updating from gnu make from 3.81 to 4.0 and using sstate-cache? Dec 14 10:33:03 I was only able to do it manually by clearing sstate cache for make-native, and only then got make 4.0 installed to all build sysroots Dec 14 10:33:13 mcfrisk: wipe tmp is the brute-force way, but there's a sanity stamp in tmp/ somewhere you can delete Dec 14 10:33:49 rburton: that did not help Dec 14 10:34:29 I had to "bitbake -c cleansstate make-native" Dec 14 10:51:45 sigh, 'bitbake make-native' builds 4.0, 'bitbake make' builds 4.0, 'bitbake -c devshell busybox' after rm -rf tmp has GNU Make version 3.81. I guess I can only remove the full 3.81 recipe to get rid of it. Dec 14 11:00:50 actually, remove the 3.81 recipe, build make-native manually, then in same sysroot busybox devshell shows make 4.0. No idea what's going on... Dec 14 11:08:44 Hey all. I've tried googling, but I cant find anything about BLAS libraries on Yocto. Is there any reason I cant find recipies? Dec 14 11:11:17 Antagonist: http://layers.openembedded.org/layerindex/branch/master/recipes Dec 14 12:04:00 Hello all, I am tasked with the replacement of a lockin amplifier, a signal generator/injector and their software with an ARM device. These high precision devices are used for a magnetic field research. I have thought of using the AD7190 as described here - https://developer.mbed.org/users/tkreyche/notebook/ad7190-ultra-low-noise-24-bit-sigma-delta-adc/ I however do not see it doing the whole job for me. Could you advise me on a better AD evaluati Dec 14 12:04:01 on board. Dec 14 12:52:25 has anybody used systemd instead of sysvinit? I see that it can be enabled by simply adding systemd into distro features but I still see rc.d directory and the ususal init scripts in my image Dec 14 12:53:46 * neverpanic is using systemd instead of sysvinit Dec 14 12:54:20 darkhorse_: as the documentation says, you'll want to remove sysvinit from your distro features if you want the rc.d files to disappear Dec 14 13:04:02 rburton: thanks. and do i need to change init symlink in the root of the image from busybox init to systemd? Dec 14 13:09:17 darkhorse_: if you've changed it to busybox, yes Dec 14 13:09:24 otherwise you'll be booting busybox still Dec 14 13:48:50 hello, I need to build a native tool which needs c++11 ( > gcc 4.8) with dizzy and ubuntu 12.04. Is it possible to build the same toolchain as target for native and keep my 4.6.2 toolchain on ubuntu Dec 14 13:49:05 or do i need to update my ubuntu toolchain ? Dec 14 13:55:29 shouldn't a native gcc be built anyways? or have i got something completely wrong here? Dec 14 13:56:51 that's what i understood from yocto...a native gcc with the same version should be built ? Dec 14 13:57:04 AFAIK yes, but i can be seriously wrong Dec 14 13:57:12 the target gcc is 4.9 Dec 14 13:57:20 and my machine is 4.6 Dec 14 13:57:47 i'm not sure to get what is the recipe name for that Dec 14 13:58:17 i'd take a good look at the environment that gets applied when building your native tool. it should tell you whats being in use. Dec 14 13:59:08 this is a custom recipe Dec 14 13:59:23 that's why i guess it needs a special dep Dec 14 13:59:56 but is there a recipe to get an host toolchain or do i need to update my toolchain ? Dec 14 14:00:01 that's the question :) Dec 14 14:00:06 it being a custom recipe doesn't mean you can't look at the environment first. Dec 14 14:00:29 i can only guess - is the recipe correctly marked as native? Dec 14 14:00:46 because then a different dependency tree gets applied. Dec 14 14:02:45 sce: there isn't a native gcc recipes in the default builds. Something like that would be possible though Dec 14 14:02:58 oki Dec 14 14:03:09 but what is "gcc" recipe ? Dec 14 14:03:33 sce: the files in meta/recipes-devtools/gcc/ Dec 14 14:03:53 this is a meta recipe ? Dec 14 14:04:43 because i never have the gcc recipe dependency in my image depexp Dec 14 14:05:15 sce: gcc is a gcc to run on the target device, "gcc-native" would be a native gcc. Usually we use a gcc-cross to build things for the target Dec 14 14:05:31 ok Dec 14 14:05:58 but gcc native is not available Dec 14 14:06:18 sce: out the box, no Dec 14 14:06:33 yes but here i need to build a binary which is native Dec 14 14:06:57 sce: I get that, I'm just trying to tell you what does and doesn't exist out the box Dec 14 14:06:59 RP: what do you advise to do ? update my distrib toolchain ? Dec 14 14:07:11 sce: or add a gcc-native recipe Dec 14 14:07:19 both have their complexities Dec 14 14:08:17 yeah and i'm surprised nobody got this case Dec 14 14:10:40 sce: I do remember writing a recipe for this, I just don't remember what I did with it. Seeing if I can find it... Dec 14 14:11:15 Dont think it builds gcc for the device unless you add tools-sdk into EXTRA_IMAGE_FEATURES I think Dec 14 14:12:50 Anyone know why there isn't a single BLAS package I can find in any meta-? ATLAS, OpenBLAS, etc Dec 14 14:16:57 Antagonist: ok that's what i was checking, the BBCLASSEXTEND is for nativesdk Dec 14 14:20:17 sce: closest I got was nativesdk-gcc: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t567&id=3b4b2f60f5b631a101b71100516bbf74bdc74f41 Dec 14 14:20:54 sce: if you add something like that patch and build a builttools-tarball containing gcc, you'd get a compiler of the version you need Dec 14 14:22:25 what is a buildtools tarball ? Dec 14 14:24:47 ok but this patch is not compatible with dizzy :( Dec 14 14:25:10 i need something i can use my production env so i guess i need to update my toolchain :( Dec 14 14:25:48 Antagonist: no BLAS because no one here has done HPC yet? recipes welcome... likely to meta-oe. Dec 14 14:52:45 ok i understand now Dec 14 14:52:53 RP: :) Dec 14 14:55:33 sce: creating a chroot / virtual machine / container is another option, as well Dec 14 14:55:34 morning all Dec 14 14:56:00 kergoth, i can use a prebuit buildtools i guess Dec 14 14:56:04 kergoth, i can use a prebuilt buildtools i guess Dec 14 14:56:19 yes, as rp said, a buildtools tarball with nativesdk-gcc would work Dec 14 14:56:25 * kergoth yawns Dec 14 15:06:03 yes that's what i'm trying to do now :) Dec 14 15:07:07 kergoth, but i guess i need this patch :( Dec 14 15:07:21 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t567&id=3b4b2f60f5b631a101b71100516bbf74bdc74f41 Dec 14 15:13:29 RP, thx for your help, the patch you provided is not landed anywhere ? Dec 14 15:13:44 i mean on a branch ? Dec 14 15:14:30 sce: no, it was never merged as there are a few nasty hacks in it Dec 14 15:14:45 relocatable gcc is a pain :/ Dec 14 15:14:49 Hi! An autoconfig project fails during the compile step with error code: "No rule to make target `motion.c', needed by `.depend'. " Does anyone know which path may be set wrong by the configure scripts? Dec 14 15:15:02 motion.c is in the same folder as Makefile Dec 14 15:32:05 RP, thx a lot anyway for the information. Dec 14 15:32:35 RP, I need to update mi distrib seen that ubuntu 12.04 does not support yocto 1.8 Dec 14 15:32:49 but it would be great to have this sandbox Dec 14 15:32:52 mrKonge: we build in a separte build directory from source directory by default. it sounds like that buildsystem can't handle it, so you should inherit autotools-brokensep instead of autotools if it really is autoconf/automake, or just set S = "${B}" for a make based buildsystem Dec 14 15:43:45 kergoth: Using autotools-brokensep worked! Thanks! Dec 14 15:44:39 np Dec 14 17:58:30 does runqemu have any parameters to give a serial console instead of vnc? Dec 14 18:00:33 obsrwr: nographic Dec 14 18:05:18 oh, yeah silly me, i was using nographic together with serial Dec 14 18:05:20 thanks Dec 14 18:23:09 morning all Dec 14 18:57:47 evening here :) Dec 14 18:59:18 Jefro, ping Dec 14 22:47:47 zeddii, awake? Dec 15 00:29:51 Hello, is there someone in here who can help me with a problem I have while using bitbake to build Yocto? Dec 15 00:30:34 I suspect you are tryin gto build Poky with openEMbedded :) Dec 15 00:30:45 but what exactly is the error? Dec 15 00:31:24 Well, the issue is, I'm trying to build it with dwarf 3 debugging info instead of dwarf 4, but I just cannot get it to compile with dwarf 3 Dec 15 00:31:31 it always ends up either failing or building with dwarf 4 Dec 15 00:31:43 hmm, I don't know much about that Dec 15 00:31:49 but maybe someon eelse does Dec 15 00:32:24 have been trying quite long already to get it to work, but without avail :( Dec 15 00:33:21 I've never even heard anyone ask that before Dec 15 00:33:21 * kergoth also knows nothing about changing the debugging info Dec 15 00:33:22 you should probably open by saying what you did to try and get dwarf 3. Dec 15 00:34:09 * deviosity is glad I'm not the only one confused by this one. Dec 15 00:34:14 as it is you've only stated your aim, not what you actually did, and you may not be doing what you think you're trying to do, iyswim. Dec 15 00:34:52 sure, let me explain Dec 15 00:36:10 I've built the yocto project with the help of the quickstart, without any special adjustments and this build just fine, however, it builds with the use of dwarf 4 (seeing as that's the standard in gcc) Dec 15 00:36:59 to adjust this, I've looked around and some people suggested adding/changing flags in the bitbake.conf file, so that you tell the compiler to build with the dwarf 3 debugging info Dec 15 00:37:56 these flags would be BUILD_CFLAGS, CFLAGS, TARGET_CFLAGS Dec 15 00:38:11 to start with, you should never need to touch bitbake.conf, you can do everything from local.conf just fine. but tell us exactly what changes you made to those flags Dec 15 00:38:24 I added -gdwarf-3 Dec 15 00:39:08 there's no need to mess with the flags directly either Dec 15 00:39:14 we have a variable for this Dec 15 00:39:16 DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types" Dec 15 00:39:23 just set DEBUG_FLAGS in local.conf to whatever you want Dec 15 00:39:56 so, like DEBUG_FLAGS = "-gdwarf-3"? Dec 15 00:39:59 in local.conf? Dec 15 00:41:12 yep Dec 15 00:41:29 sure, let me try that Dec 15 00:44:06 maybe silly question, but is there a way to quickly see that it works, without building entire yocto? Dec 15 00:44:32 build just one of the early recipes, I guess. Dec 15 00:46:04 sure, thanks in advance guys, if it works you'll be my heroes :D Dec 15 00:53:11 good luck Dec 15 01:13:08 * armpit wonders if I would get reprimanded if I log a bug from OSS that contained the F word **** ENDING LOGGING AT Tue Dec 15 02:59:58 2015