**** BEGIN LOGGING AT Fri Sep 22 03:00:00 2017 **** BEGIN LOGGING AT Fri Sep 22 06:00:49 2017 Sep 22 13:26:52 khme: i am not sure they are applied correctly, also i do not know yet which are options, which are flags, and which are for the yocto sdk itself (not for compiler, assembler, linker) Sep 22 13:29:42 khem: (resend to correct username spelling) i am not sure they are applied correctly, also i do not know yet which are options, which are flags, and which are for the yocto sdk itself (not for compiler, assembler, linker) Sep 22 14:00:08 see CFLAGS and CXXFLAGS etc at well Sep 22 14:00:29 you need to add that too, in the end they are two things compiler + options Sep 22 14:00:53 you may get them through different variables Sep 22 14:02:23 here is the environment file: https://pastebin.com/KGL8YAM0 Sep 22 14:04:53 i added flags? to the gcc cross Miscellaneous Other FLags Sep 22 14:06:37 specifically the CC line starting with -march Sep 22 14:06:54 and the same for g++ cross for the cxx line Sep 22 14:08:08 i should probably just remake projects as makefile and use the sdk makefile Sep 22 14:12:53 i added the LD line to Miscellaneous Linker Flags starting with --sysroot Sep 22 14:14:05 the LDFLAGS caused linker failures Sep 22 14:21:53 khem: is it possible to use the toochain i installed to generate the correct makefile project or makefile? Sep 22 15:25:07 yes Sep 22 15:25:17 source environment file Sep 22 15:25:30 and then use CC/CXX etc in your makefiles Sep 22 15:34:35 that's pretty much the same as the eclipse project, i doubt it will resolve the issue Sep 22 15:35:25 i'll have to figure out some other solution Sep 22 15:51:17 that's how you do it. if there's a problem with using it, you should look into the root cause ofthe actual failures you're seeing, rather than trying random stuff :) Sep 22 16:01:31 zarzar1: what errors do you see. Sep 22 16:01:59 Can you make eclipse to dump the build logs in verbose mode somewhere and compare the options being used ? Sep 22 16:02:01 kergoth: are you responding to me? Sep 22 16:02:22 yes there is only this thread happening today Sep 22 16:03:01 well in my opinion yocto should be using official releases of toolchains not some random snapshotsd Sep 22 16:03:37 have you even bothered to isolate the problem to a particular toolchain version? if not, i don't see what you're complaining about Sep 22 16:03:51 this choice has made it almost impossible to replicate Sep 22 16:04:32 kergoth i am restricted to using 4.8.1 cross toolchain that was used in yocto dora 1.5 Sep 22 16:05:46 but since yocto uses snapshots of toolchain and builds from the source it is very difficult to remake that cross toolchain version Sep 22 16:05:52 zarzar1: yocto integrates a lot of packages to build a system, so our considerations are not same as upstream packages sometimes, they may not see improtantance of a platform that we do and vice versa therefore many times we may not use standard releases even though thats rare Sep 22 16:06:07 khem: i'm sure there are advantages Sep 22 16:06:47 it's like any other distro, really. plenty of distros have to patch up projects or use different revs to deal with various issues in integration.. Sep 22 16:06:48 zarzar1: I know you are looking for a binary toolchain, but yocto is not into that business, you might have OSVs and tools vendors for that Sep 22 16:06:48 but the disdvatage is when someone only wants to develop applications for a system with a restriction to use the same toochain Sep 22 16:07:11 zarzar1: yes we do provide locked shared state now a days Sep 22 16:07:23 but not for that version you are locked at Sep 22 16:07:55 if you share the build logs etc. we may be able to help you more Sep 22 16:08:15 that's ok, too much time spent already, too many issues Sep 22 16:08:46 thanks for all the help khem Sep 22 16:08:58 no worries, Sep 22 16:08:59 i learned quite a bit in the process Sep 22 16:09:24 :), I am sure you are close to solving it Sep 22 16:10:06 khem: doubtful Sep 22 16:10:28 share build logs and errors so we can see whats going on Sep 22 16:10:37 or may be errors atleast Sep 22 16:10:39 already reverted the projects Sep 22 16:10:56 ok Sep 22 16:11:01 good luck Sep 22 16:11:39 the build was fine anyway, it just didn't run on target, so the issue could have been all the way back at the toolchain installer build step Sep 22 16:11:51 too many variables for me Sep 22 16:12:29 too many variables, too many steps, too risky, probably errror prone process Sep 22 16:14:01 yeah yocto does have possibility to hook in binary toolchains though, may be thats what your project should have done from day 1 in that case use something like codesourcery or other binary toolchain Sep 22 16:16:46 khem: it wasn't my project, it was openssl validated system Sep 22 16:17:17 they used kernel 3.10 yp 1.5 with 4.8.1 toolchain Sep 22 16:17:38 very very difficult to replicate now Sep 22 18:48:44 kergoth: I did found that pkgconf will need some love. You did include a wrapper to iron out the sysroot when calling it as pkgconfig however it breaks some valid use cases. wayland-protocols for example now adds: https://patchwork.openembedded.org/patch/144428/ (see the backported patch) which adds ${pc_sysrootdir} Sep 22 18:49:04 kergoth: pkgconf has support for ${pc_sysrootdir} but it only works when the sysroot var is set Sep 22 19:23:29 otavio: interesting. it's entirely possible that the behavior of pkgconf has changed since i wrote the initial bits for it, iirc i added the prototype layer to my wip repo a copule years ago i think. woudln't surprise me if there's a kink or two left. it wasn't me that integrated and submitted it. should likely install both on a system and compare current behaviors Sep 22 19:24:22 kergoth: or just drop the wrappers as it seems it is well supported (as Fedora uses it) Sep 22 19:26:01 kergoth: I was testing it here and it does have some corner cases. As OE-Core and Poky does not use it by default it is not critical for release but it'd be worth Mentor taking a look at this Sep 22 19:26:46 yeah, dropping the wrapper seems entirely reasonable to me, as long as it doesn't break anything Sep 22 19:27:06 kergoth: is it possible for someone at your side look at it? Sep 22 19:27:26 kergoth: I cannot look at it in short term Sep 22 19:27:40 np, i'll see if i can find the resources here Sep 22 19:27:48 kergoth: thx! Sep 22 19:27:50 shoudln't take too long Sep 22 19:27:50 np Sep 22 19:28:31 kergoth: also ... with the removal of update-alternatives on kernel, chkconfig update-alternatives are good again Sep 22 19:29:13 RP: ^ kergoth is going to look at the pkgconf issue I mentioned before Sep 22 21:20:34 otavio: ok, thanks **** ENDING LOGGING AT Sat Sep 23 03:00:02 2017