About mixing branches - I have recreated the problem on new location to check that the problem persist. Here is new setup: BB_VERSION = "1.36.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "am335x-evm" DISTRO = "poky" DISTRO_VERSION = "2.4.1" TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" TARGET_FPU = "hard" meta = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d" meta-oe = "rocko:6e3fc5b8d904d06e3aa77e9ec9968ab37a798188" meta-et = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d" meta-ti = "master:8fcd2f60720acf46555b45a1a48ad1fa0c52b75a" meta-qt5 = "rocko:d87335a50a9dd35d890786edbd79b8953fdaa11a" meta-poky meta-yocto-bsp = "rocko:abec40e5ebc6f1b804cf698e365737224a57c41d"
meta-poky is in rocko too - I don't know why it didn't show but I have double checked it. meta-ti does'nt have rocko, so it is in master. This time, as I am using poky, after deploying and sourcing sdk I had to copy ./sysroots/x86_64-pokysdk-linux/ to ./sysroots/x86_64-oesdk-linux/ so it's basicly the same and it doesn't make difference if I build it with "bitbake <image> -c populate_sdk" or "bitbake meta-toolchain-qt5" - result is the same (not counting that second option doesn't give me additional libs from my image). Recipe with our own applications has same issue as on my previous setup. As I have written - the problem is not in generated sdk that I use for out-of-yocto build, but it is when I build my code within yocto with recipe and image. To answer your question about image - on my setup I have my own image recipe, now on this test setup i used core-image-minimal with additional qt packages added via local.conf file. To sum up: There are two problems: first is when using generated sdk - the problem is that in sdk subdirectories there is x86_64-pokysdk-linux, but cmake is looking for x86_64-oesdk-linux. This can by bypassed copying *pokysdk* to *oesdk*. second problem is when building from recipe - it looks similar, but I can't find proper directories to try out solution which I just described in first problem. I hope it is now clearer what my problem is. Regards, Marek pon., 18 gru 2017 o 23:30 użytkownik Mirza Krak <mirza.k...@gmail.com> napisał: > 2017-12-18 12:11 GMT+01:00 Marek Słomiany <marekslomi...@gmail.com>: > > Hi, I'm having problem while building Qt application inside of yocto and > > using generated SDK. > > I have bypassed it when using generated SDK, which I describe here. > > > > My setup in short: > > I'm using for Qt this layer git://github.com/meta-qt5/meta-qt5.git in > rocko > > branch > > beside Qt, other layers that might be important: > > meta-poky (rocko) > > meta-oe (morty) > > meta-python (morty) > > meta-networking (morty) > > meta-ti (morty) > > First of, why are you mixing branches here? You should use the same > branch on all the layer for better chances for it to work > out-of-the-box. There have been a lot of changes to the "core" from > morty to rocko and trying to mix them probably raises some "extra" > problems that you would not normally get. > > > > > The platform is am335x > > distro name is "etos" > > > > I had some problems with sdk (at first I added Qt to my build but > > applications were developped and build by my coleagues using external > > toolchains). > > Recently I've added recipes for those apps to my layer. > > To test if code I got from my team is building fine, I have generated SDK > > using "bitbake <image-name> -c populate_sdk" and deployed it in default > path > > which is /opt/etos/1.0/. When I have sourced it and tried to configure I > > got: > > What image did you build when you generated the SDK? > > meta-qt5 seems to provide a recipe for a toolchain containing all the > Qt stuff including qmake [1]. Try that out if you haven't already by > simply running: > > bitbake meta-toolchain-qt5 > > [1]. > https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/meta/meta-toolchain-qt5.bb > > -- > Med Vänliga Hälsningar / Best Regards > > Mirza Krak >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto