**** BEGIN LOGGING AT Mon Mar 02 02:59:58 2015
Mar 02 08:56:22 <dol> hi guys. I use "std::unique_ptr" in my code in one of my packages and I already included "#include <memory>" as header. However I still get "error: 'unique_ptr' is not a member of 'std'" when building the package. Can anyone tell me why I still get it?
Mar 02 08:58:03 <woglinde> dol hm
Mar 02 08:58:11 <woglinde> I think you are on the wrong channel
Mar 02 08:58:39 <dol> woglinde, I asked here because I thought it could be a build issue with oe.
Mar 02 08:58:56 <dol> i.e. I don't add dependency so on
Mar 02 08:59:54 <woglinde> dol did you prove it, with compiling on debian or ubuntu?
Mar 02 09:00:34 <dol> I personally not.
Mar 02 09:16:56 <afournier> morning !
Mar 02 09:18:36 <afournier> is it possible to modify opkg's lock default location ?
Mar 02 09:32:37 <khem`> dol uniq_ptr is a c++11 feature have you enabled it ? -std=c++-11
Mar 02 09:37:46 <woglinde> what the hell
Mar 02 09:37:59 <woglinde> ncp is buying freescale for 12 billion
Mar 02 09:38:12 <woglinde> args nxp
Mar 02 09:38:16 <woglinde> I meant
Mar 02 09:47:09 <mckoan> woglinde: yes I know is a hot news
Mar 02 12:41:30 <mago_> hey all
Mar 02 16:05:07 <florian> woglinde: Do you accept patches for meta-telephony? :)
Mar 02 16:17:36 <woglinde> florian zecke does
Mar 02 16:19:06 <florian> woglinde: "zecke deleted sysmocom-openembedded/meta-telephony 2014-10-07 14:54:26 UTC"
Mar 02 16:19:30 <florian> woglinde: yours is the last remaining one
Mar 02 16:19:31 <Crofton|work> hmm, did he move it
Mar 02 16:19:57 <Crofton|work> http://layers.openembedded.org/layerindex/branch/master/layer/meta-telephony/
Mar 02 16:20:17 <florian> yep
Mar 02 16:20:20 <Crofton|work> I really need to do some work with it
Mar 02 16:20:30 <florian> looks like he moved to github
Mar 02 16:22:50 * florian dreams of the past... when we not hat to track 1000 randomly moving layers
Mar 02 16:23:47 <Crofton|work> the layer index helps
Mar 02 16:24:08 <Crofton|work> and if I remember, we used to be annoyed about the sheer number of recipes in one layer :)
Mar 02 16:25:36 <florian> sure, but on the on ehand it does not gurantee anything about the layer or the information about it... and you still have to query it layer by layer
Mar 02 16:25:47 * florian did not
Mar 02 16:29:58 <koen> when I asked zecke about the move he said "Wow, someone is actually using it? Sorry about moving it"
Mar 02 16:32:49 <nerdboy> moin
Mar 02 16:33:41 <kergoth> hah
Mar 02 16:35:56 * nerdboy can't find the espresso IV kit...
Mar 02 17:18:06 <woglinde> florian yes we moved to github gitoriuos
Mar 02 17:18:13 <woglinde> is so unstable
Mar 02 17:34:08 <khem`> gitorious sucked for me too
Mar 02 18:16:05 <koen> khem: I wouldn't mind the downtime so much is gitorious would actually say it's down (on e.g. twitter) and then tell us why it went down
Mar 02 18:16:08 <koen> like github does
Mar 02 20:38:30 <Jin^eLD> hmm, if a package has only a makefile (no configure or anything), what should be inherited? autotools-brokensep?
Mar 02 20:42:25 <woglinde> nothing
Mar 02 20:42:42 <Jin^eLD> I had a case when the ipk turned out empty then
Mar 02 20:43:02 <woglinde> adjust do_compile and do_install
Mar 02 20:43:09 <Jin^eLD> you mean - write them myself?
Mar 02 20:43:16 <woglinde> partly
Mar 02 20:43:19 <Jin^eLD> i.e. just call oe_runmake etc?
Mar 02 20:43:37 <woglinde> yes
Mar 02 20:43:49 <woglinde> and do run bitbake -c do_package
Mar 02 20:44:03 <Jin^eLD> you mean to test? or why?
Mar 02 20:44:07 <woglinde> and examine the build directory
Mar 02 20:44:14 <Jin^eLD> ah
Mar 02 20:44:15 <woglinde> to see where what stuff ends up
Mar 02 20:44:20 <Jin^eLD> I get the idea I think
Mar 02 20:44:33 <Jin^eLD> I used autotools-brokensep which kind of did all correctly, but was just wondering
Mar 02 20:44:40 <woglinde> thats how I do it
Mar 02 21:00:49 <khem> autotools classes need to have configure in src 
Mar 02 21:01:04 <khem> dont use them when components dont use autotools
Mar 02 21:01:54 <Jin^eLD> khem: it works though :) but if it has some implications I would redo the recipes with manual do_compile/do_install
Mar 02 21:02:39 <khem> Jin^eLD: its like saying if I see the lion, i will close my eyes. and since I cant see the lion therefore lion is not able to see me 
Mar 02 21:03:15 <Jin^eLD> :)
Mar 02 21:03:44 <Jin^eLD> so basically it would probably make sens to write an own bbclass which just does call make and DESTDIR=bla make install?
Mar 02 21:03:55 <khem> problem is you may come back and ask questions here on the very same frankenstein
Mar 02 21:04:08 <khem> its fine if pain infliction was local
Mar 02 21:05:24 <khem> many time you get good suggestions here. My recommendation is to listen to it
Mar 02 21:05:27 <khem> :)
Mar 02 21:06:01 <Jin^eLD> khem: I do :) hence my question about an own bbclass which would spare me the manual do_compile/do_install for each of those recipes?
Mar 02 21:06:12 <Jin^eLD> would that be an acceptable way?
Mar 02 21:06:29 <khem> sure, that would be ok
Mar 02 21:06:59 <Jin^eLD> ok, thanks, I'll do it like that then
Mar 02 21:07:14 <abelloni> what if the lion is not hungry? :)
Mar 02 21:08:28 <Jin^eLD> or lost his glasses :P
Mar 02 21:13:02 <khem> abelloni: replace lion with 'hungry lion with glasses'
Mar 02 21:14:41 <Jin^eLD> khem: I remember you told me that u-boot needs to be compiled with soft float, how does OE ensure that for the uboot package only?
Mar 02 21:15:03 <Jin^eLD> or in other words: I was slowly working through a gazillion ofmy failing packages when migrating to poky 1.7.x and now came to u-boot :)
Mar 02 21:15:15 <Jin^eLD> but unlike with the others I am not sure what to do here
Mar 02 21:17:29 <Jin^eLD> although I found an imx uboot, investigating how it is doing things
Mar 02 21:17:30 <Jin^eLD> lets see...
Mar 02 21:30:20 <abelloni> can't you simply use the u-boot recipe ?
Mar 02 21:30:54 <abelloni> I would believe that the u-boot makefile is doing the right thing
Mar 02 21:54:15 <adelcast> hello, I am adding the Salt minion (system configuration software) to my distro. The Salt minion requires python, and with all it's dependencies I am seeing a footprint increase of 88.6 MB
Mar 02 21:55:26 <adelcast> I am trying to determine the best way to reduce the footprint...digging around I found that the code to generate python packages comes from scripts/contrib/python/generate-manifest-2.7.py
Mar 02 21:56:26 <adelcast> is my best bet to directly override python-2.7-manifest.inc to remove RDEPENDS on ${PN}-modules ?
Mar 02 21:58:17 <adelcast> I believe I could also zip everything up, as python can run from a compressed file, but then my recipe would be pretty much overwriting everything on the original recipe...so I am not sure what is the best way to go from here
Mar 02 23:39:49 <Jin^eLD> abelloni: well, it does not seem like that, and I have the feeling that it needs a different toolchain
Mar 02 23:41:15 <Jin^eLD> error is fatal error: gnu/stubs-soft.h: No such file or directory
Mar 02 23:41:26 <Jin^eLD> which makes sense because theis is a hardfloat toolchain
Mar 02 23:41:31 <abelloni> that has not been the case since at least 10 years
Mar 02 23:41:46 <Jin^eLD> hmm
Mar 02 23:42:06 <Jin^eLD> khem told me that poky switched to hardfloat (for imx at least), and also that u-boot still needs to be compiled with soft float
Mar 02 23:42:27 <Jin^eLD> and I can't figure out how this is done
Mar 02 23:42:56 <Jin^eLD> we have our own uboot recipe which inherits poky's u-boot.inc but it fails to build
Mar 02 23:43:27 <Jin^eLD> it did build with poky 1.5.x because there poky was using soft float and thus the toolchain was softfloat 
Mar 02 23:43:27 <abelloni> I'm always using an hard float toolchain
Mar 02 23:43:31 <Jin^eLD> and it all matched together
Mar 02 23:43:35 <Jin^eLD> so how do you compile u-boot then?
Mar 02 23:43:36 <abelloni> and I build u-boot and the kernel just fine
Mar 02 23:43:54 <abelloni> it simply doesn't matter as they are not using floating points
Mar 02 23:46:25 <Jin^eLD> well the problem are the gnu stub defines
Mar 02 23:46:33 <Jin^eLD> the header is not present on a hardfloat toolchain
Mar 02 23:48:51 <abelloni> can youshow me where they are actually used ?
Mar 02 23:54:32 <Jin^eLD> ok, its a bit a long chain though
Mar 02 23:56:14 <Jin^eLD> so this is the overall output:
Mar 02 23:56:17 <Jin^eLD> and if plucked apart:
Mar 02 23:56:30 <Jin^eLD> uboot includes stdint.h: https://gitorious.digitalstrom.org/dss-oe/u-boot-icnexus/blobs/master/sabrelite-u-boot-android/include/compiler.h#line19
Mar 02 23:57:00 <Jin^eLD> this rolles down the chain to features.h which does:
Mar 02 23:57:02 <Jin^eLD> #include <gnu/stubs.h>
Mar 02 23:57:35 <Jin^eLD> the content of stubs.h is this: https://pastebin.mozilla.org/8823953
Mar 02 23:57:43 <Jin^eLD> the defines are set by the compiler
Mar 02 23:58:07 <Jin^eLD> the OE toolchain that was built for imx only provides stubs-hard.h
Mar 02 23:58:24 <Jin^eLD> so its actually correct that uboot is looking for stubs-soft.h
Mar 02 23:58:32 <Jin^eLD> that means the compiler got the appropriate flag
Mar 02 23:58:38 <Jin^eLD> but the header is missing in the sysroot
Mar 03 00:01:46 <abelloni> which is not the issue you are looking for
Mar 03 00:02:27 <abelloni> I'd say that something messes with you compiler flags
Mar 03 00:02:43 <Jin^eLD> why? the compiler flags are correct
Mar 03 00:02:50 <Jin^eLD> it does try to include the soft stubs
Mar 03 00:02:53 <Jin^eLD> which is OK for uboot
Mar 03 00:02:58 <Jin^eLD> or am I mistaken?
Mar 03 00:03:53 <kergoth> perhaps you need to enable multilibs and configure MULTILIBS for hard and soft float, so the compiler gets configured for both?
Mar 03 00:03:56 <abelloni> I'm building u-boot just fine with an hf toolchain 
Mar 03 00:04:09 <abelloni> and they don't have stubs-soft.h
Mar 03 00:04:27 <Jin^eLD> ok let me check the manual on how this is done...
Mar 03 00:04:33 <abelloni> either the linaro one or the oe generated one
Mar 03 00:04:37 <Jin^eLD> abelloni: well, question then is - hy does it work for you? :P
Mar 03 00:04:42 <Jin^eLD> *why
Mar 03 00:04:55 <abelloni> or why it doesn't work for you
Mar 03 00:05:08 <Jin^eLD> although I remember khem mentioning that hard/soft is not being tracked for multilib?
Mar 03 00:05:09 <abelloni> and I believe something messes your CFLAGS
Mar 03 00:05:57 <Jin^eLD> hm
Mar 03 00:09:31 <abelloni> di you try to compile with the linaro toolchain ?
Mar 03 00:09:47 <abelloni> the hf one :)
Mar 03 00:09:49 <Jin^eLD> uh.. not sure? :) I set the machine to imx and off we go
Mar 03 00:09:56 <Jin^eLD> I did not mess around with the toolchain
Mar 03 00:10:29 <abelloni> doing that would rule out any issues in the codebase
Mar 03 00:10:33 <onoffon> are you using -mfloat-abi=hard
Mar 03 00:10:53 <khem`> issue is genuine 
Mar 03 00:10:58 <Jin^eLD> https://gitorious.digitalstrom.org/dss-oe/dss-oe/blobs/master/yocto/dS/meta-digitalstrom-devel/conf/machine/dss11e.conf <- this is my machine config
Mar 03 00:11:39 <khem`> gcc defines __ARM_PCS_VFP if ARM_PCS_AAPCS_VFP is set and ARM_PCS_AAPCS_VFP is set when you pass -mfloat-abi=hard
Mar 03 00:11:52 <Jin^eLD> right
Mar 03 00:11:56 <khem`> can uboot be compiled with hardfp
Mar 03 00:12:04 <khem`> if not then there is an issu 
Mar 03 00:12:15 <Jin^eLD> that I do not know.. you told me u-boot is compiled with soft float?
Mar 03 00:12:16 <abelloni> u-boot just doesn't care
Mar 03 00:12:30 <Jin^eLD> if u-boot does not care, then my CFLAGS are indeed wrong
Mar 03 00:12:32 <abelloni> there a no floating point in u-boot
Mar 03 00:12:37 <abelloni> are
Mar 03 00:13:08 <khem`> then respect CC from env and rest the case 
Mar 03 00:13:32 <khem`> why is uboot overriding CC and its ilk ?
Mar 03 00:13:57 <Jin^eLD> good question, since its some customized u-boot the prohlem might be there
Mar 03 00:13:59 <Jin^eLD> I will investigate then
Mar 03 00:14:04 <Jin^eLD> I thought its a must for it to be soft float
Mar 03 00:14:13 <Jin^eLD> but if that is not the case, then abelloni is surely right when he says my CFLAGS are wrong
Mar 03 00:15:21 <abelloni> arm-linux-gnueabihf-gcc -Wp,-MD,arch/arm/lib/.cache.o.d  -nostdinc -isystem /home/alex/bin/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/include -Iinclude  -I/home/alex/Projects/atmel/u-boot/arch/arm/include -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x26f00000 -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -g -fstack-usage -Wno-format-nonliteral -DCON
Mar 03 00:15:35 <abelloni> that's what I get
Mar 03 00:15:52 <Jin^eLD> no -mfloat-abi though?
Mar 03 00:15:58 <abelloni> -msoft-float is passed
Mar 03 00:16:09 <Jin^eLD> ah, it is? am I blind, where
Mar 03 00:16:18 <abelloni> before -pipe
Mar 03 00:16:25 <abelloni> maybe it got cut
Mar 03 00:16:57 <fray> either your tune is wrong, or the toolchain configuration is wrong..
Mar 03 00:16:58 <abelloni> http://code.bulix.org/6cnqcf-87960
Mar 03 00:17:09 <fray> seeing how this is a linaro toolchain, you'll have to look at both of them and figure out where the mismatch is
Mar 03 00:17:37 <abelloni> fray: non, I'm using a linaro toolchain as a working  example
Mar 03 00:17:47 <fray> also depends on what you are building, this looks like firmware or a module.. most of hte time hard float ABI isn't supported there
Mar 03 00:17:54 <abelloni> Jin^eLD is using an oe toolchain
Mar 03 00:18:33 <Jin^eLD> abelloni: and you have no stubs-soft.h in sysroots/YOURMACHINE/usr/include/gnu
Mar 03 00:18:34 <Jin^eLD> ?
Mar 03 00:18:34 <abelloni> like I said, kernel, modules and bootloaders just don't care
Mar 03 00:18:35 <fray> if you use a binary toolchain you need to have an understanding of what it might be defaulted to.  You can query the gcc spec file and figure it out if you need to..
Mar 03 00:18:45 <abelloni> Jin^eLD: nope
Mar 03 00:19:04 <fray> it's not that they don't care, its that they have no floating point exception handling so generally they don't enable floating point adn the rest of the ABI is irrelevant
Mar 03 00:19:13 <Jin^eLD> well then I do not understand how it works, because if you pass soft float option then it boils down to the gcc defines that khem mentioned above
Mar 03 00:19:25 <Jin^eLD> and then soft-stubs should be included - which would lead to an error if you do not have them
Mar 03 00:20:17 <abelloni> Jin^eLD: can you use make V=1 and compare the log?
Mar 03 00:20:24 <Jin^eLD> sure, just started devshell
Mar 03 00:20:49 <khem`> abelloni, unfortunately they do have to care about whats being included from compiler headers 
Mar 03 00:20:50 <abelloni> Jin^eLD: I built all the boards from meta-fsl-arm and meta-fs-arm-extra yesterday
Mar 03 00:21:11 <abelloni> so I'm pretty sure u-boot builds with an hf toolchain for imx
Mar 03 00:21:23 <khem`> gcc does not create defaults for float-abi 
Mar 03 00:21:25 <khem`> thats the core issue 
Mar 03 00:21:30 <khem`>               case "$with_float" in
Mar 03 00:21:31 <khem`>                 "" \
Mar 03 00:21:31 <khem`>                 | soft | hard | softfp)
Mar 03 00:21:31 <khem`>                         # OK
Mar 03 00:21:33 <khem`>                         ;;
Mar 03 00:21:33 <khem`>                 *)
Mar 03 00:21:59 <khem`> so even if you did --with-float-abi=hard nothing it means 
Mar 03 00:22:10 <khem`> as far as defaults are concerned 
Mar 03 00:22:29 <khem`> so only way to default to hf is use -mfloat-abi=hard 
Mar 03 00:22:39 <khem`> someone could patch gcc 
Mar 03 00:24:46 <Jin^eLD> https://pastebin.mozilla.org/8823965
Mar 03 00:25:06 <Jin^eLD> I have quite weird flags actually, -msoft-float and -mabi=aapcs-linux
Mar 03 00:26:23 <khem`> folks just symlink stubs-soft.h to stubs-hard.h  and get along 
Mar 03 00:26:27 <khem`> but thats a landmine 
Mar 03 00:26:39 <Jin^eLD> yeeeah that reminds me of the lion story :)=
Mar 03 00:27:07 <Jin^eLD> I'd rather patch uboots CFLAGS
Mar 03 00:27:13 <khem`> get rid of -msoft-float
Mar 03 00:27:26 <khem`> that just means -mfloat-abi=soft
Mar 03 00:27:46 <khem`> -mabi is ok
Mar 03 00:28:15 <abelloni> -march=armv5 is weird on i.mx5
Mar 03 00:28:30 <khem`> unless uboot uses functions which pass floating point data in parameters you are safe with -mfloat-abi=hard
Mar 03 00:29:11 <Jin^eLD> hmm, this hello world is actually an example that it tries to compile for some reason
Mar 03 00:35:06 <khem`> I wonder if your defconfig for uboot is correctly matching your h/w platform at all
Mar 03 00:36:58 <Jin^eLD> that's where I have to ask around I guess, I'm a userspace guy
Mar 03 00:37:16 <Jin^eLD> it's using mx6q_sabrelite_config
Mar 03 00:37:27 <Jin^eLD> I could not find anything msoft-float related in it though
Mar 03 00:37:35 <Jin^eLD> but I do not yet understand the u-boots build system
Mar 03 00:38:20 <Jin^eLD> that's something for tomorrow I guess
Mar 03 00:38:23 <Jin^eLD> thanks everyone
Mar 03 00:38:25 <Jin^eLD> nite
Mar 03 02:37:50 <otavio> is soneone using QEMU x86 with OpenGL?
**** ENDING LOGGING AT Tue Mar 03 02:59:58 2015