**** BEGIN LOGGING AT Sat Nov 05 03:00:01 2016 Nov 05 12:09:46 i try to write a recipe for ettercap network tool Nov 05 12:10:22 and i can't figure out why it _always_ try to use my host (x86_64) headers even if everything is present on my target (raspberry2) include dir Nov 05 12:10:36 ettercap use cmake as build system Nov 05 12:11:46 here is my recipe : http://pastebin.com/iFJxM0L0 Nov 05 12:12:13 my SRC_URI points to https://github.com/Ettercap/ettercap/archive/v0.8.2.tar.gz wich bundle libcurl Nov 05 12:13:12 it's looks like EXTRA_OECMAKE isn't taked into account or not completly, like it ignores -DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_HOST} Nov 05 14:25:19 hello everybody. How can I change the default optimization level from -O2 to -O3? I can't find this setting? Nov 05 14:25:53 I read today some artical about optimization. And I think it will be usefull to compile the project over weekend with this level :3 Nov 05 14:25:56 https://wiki.linaro.org/MichaelHope/Sandbox/BuildingAtO3 Nov 05 14:32:11 I found the flag http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-FULL_OPTIMIZATION Nov 05 14:32:33 At the directory oe-core/stuff/openembedded-core/meta/conf in file bitbake.conf Nov 05 14:32:48 I don't want to modify this layer, can I add this somewhere in my meta-layer? Nov 05 14:44:40 I have added to my own meta-layer (oe-core/stuff/meta-xxx/conf/layer.conf) but this is not working... Nov 05 14:47:36 Please help me. I stay here Nov 05 15:52:52 HyP3r: you should be able to do something like this in your local.conf Nov 05 15:53:39 FULL_OPTIMIZATION_remove = "-O2" Nov 05 15:53:55 FULL_OPTIMIZATION_append = " -O3" Nov 05 15:55:00 O3 is very agressive, you are giving the compiler licence to go amok Nov 05 15:55:21 just be aware Nov 05 15:55:37 I would absolutely not do that. Nov 05 15:57:49 seebs: for fun its ok :) Nov 05 16:28:57 seebs and khem really? Is that really not a good idea? I'm just wokring on a image which gets deployed on more than hundred devices all over the world Nov 05 16:29:10 khem: thanks for this tipp, I'll try that Nov 05 16:29:30 So, long story short: Compilers are dark magic, and they absolutely have bugs, and there's no significant test coverage at -O3. Nov 05 16:29:48 There's been lots of historical examples (many may have been fixed now) of things that were known to only work at specific optimization levels. Nov 05 16:30:01 ok Nov 05 16:30:04 For instance, at one point I believe ARM kernels did not work if compiled with any optimization other than -Os. Like, just plain didn't work. At all. Nov 05 16:30:22 I have ready today that we _now_ don't have to worry about this, because those critical level 3 errors were fixed Nov 05 16:30:47 Maybe! The problem is, there's not enough actual test coverage happening for anyone to know for sure. Nov 05 16:31:09 So... For a personal project where it's no big deal if you have problems? Sure. Business-critical production? Absolutely not. Nov 05 16:31:10 But ok. I'll let my test team do some thorough investigation Nov 05 16:31:35 I'm more in thie Business-critical production Sector ... Nov 05 16:31:46 When its not working I go back to O2 Nov 05 16:32:21 Hehe the image is now 5MB bigger with O3 Nov 05 16:33:57 I have never heard from the removal statement (generally) http://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#removing-override-style-syntax Nov 05 16:34:02 Really nice thing Nov 05 16:46:38 HyP3r: if you are thinking production you must be conservative, its always advised to use the most common case Nov 05 16:46:41 which is -O2 Nov 05 16:47:00 gcc received maximum testing coverage with this option Nov 05 16:48:05 so chances of running into compiler bugs will be low, moreover, as we know many softwares are written to the best what compiler can do, and if you change opt level it can reveal hidden bugs in packages themselves Nov 05 16:48:19 none of these cases are acceptable but its reality Nov 05 19:08:25 khem: okay I go back to normal O2 optimization (hehe "normal") **** ENDING LOGGING AT Sun Nov 06 02:59:59 2016