**** BEGIN LOGGING AT Wed Nov 28 03:00:01 2018 Nov 28 08:13:00 Alright, I'm back at it again... still trying to get a binary native package into my sysroot. Everything indicates this should be really easy, but nothing works. Nov 28 08:16:00 I'm now trying ton install all the files in ${D}${datadir}, because datadir is in SYSROOT_DIRS. But nothing happens... Nov 28 08:17:28 It now installs into ./tmp/work/x86_64-linux/dds-native/5.3.1-r6/image/home/rove/code/poky/rpi-build/tmp/work/x86_64-linux/dds-native/5.3.1-r6/recipe-sysroot-native/usr/share/rti_connext_dds-5.3.1 Nov 28 08:26:44 Hmmm, getting closer Nov 28 08:50:49 Ok, it kinda works. More details... Nov 28 08:52:38 Right now I symlink the binaries into bindir so they are found, and then I use readlink -f $(which rtipkginstall) to find their actual location so I can run them without failures. Nov 28 09:00:47 cool, this works nicer export NDDSHOME=${STAGING_DIR_NATIVE}/usr/share/rti_connext_dds-${PV} Nov 28 09:03:03 WARNING: dds-native-5.3.1-r6 do_populate_sysroot: File 'somebinary' from dds-native was already stripped, this will prevent future debugging! Nov 28 09:31:31 what's the supposed way to unset a `PREFERRED_PROVIDER`? Nov 28 09:32:10 s/supposed/recommended Nov 28 09:32:49 T_UNIX: not setting it, in the first place. Nov 28 09:33:08 it's set by some `.inc` of another layer :-/ Nov 28 09:33:58 T_UNIX: does that sentence virtually continue with "... pulled in by a premade DISTRO or MACHINE i use"? Nov 28 09:34:43 more or less ;-D Nov 28 09:34:44 because in that very common case, your answer is: create a custom MACHIEN or DISTRO based off that one, and adjust it to your needs. Nov 28 09:34:59 that's what I already did Nov 28 09:35:11 then you're doing it wrong. Nov 28 09:35:29 I'm reusing that `.inc`, yet it's a single line that is "unwanted" Nov 28 09:36:06 then don't reuse it. if its in a layer you don't control, then you will run into troubles anyways if somebody updates it for reasons beyond your likings. Nov 28 09:36:17 copy it over to your layer, nail it down. Nov 28 09:36:41 that's what I do by using git. Nov 28 09:36:59 but I got your point Nov 28 09:37:03 well you asked for the recommended way :-) Nov 28 09:37:17 the technically possible way is: overwrite it after the include. Nov 28 09:37:20 thank you :) Nov 28 09:37:30 but i explicitly discourage that. Nov 28 09:37:56 LetoThe2nd: yeah, that's what I just did. But I'll amend that to go the recommended way. Nov 28 10:13:34 has anybody here run into the situation that open() on target always aborts with EPERM, and doesn't even make to strace, while the same come works nicely on the dev host? usual reasons as uid tinkering and O_NOATIME flags don't apply. Nov 28 10:13:57 well that sounds broken in a really special way Nov 28 10:13:58 congrats Nov 28 10:14:03 hooray. :-( Nov 28 10:15:09 could at least kinda understand it if it was limited to a specific, maybe special filesystem. but it now fails always, even in tmpfs Nov 28 10:15:32 how does *anyting* work if open() fails? Nov 28 10:16:15 rburton: the fun part is that the system seems to work fine. just my current dev task which i deploy through devtool fails. Nov 28 10:26:15 can i somehow get the version of a dependency? Nov 28 10:33:33 pepijndevos: hum, whats the usecase? Nov 28 10:38:51 LetoThe2nd, the package installed into somedir-, so now I want to refer to that directory Nov 28 10:39:16 sounds like a broken install process. Nov 28 10:40:21 well... it's a binary installer that you can give a prefix that it then adds its version number to. I guess I could manually rename it afterwards... Nov 28 10:40:29 i'd just symlink it to a known place. Nov 28 10:48:09 LetoThe2nd, everything breaks horribly when i do that. It's just horrible software I'm installing. Nov 28 10:48:30 * LetoThe2nd shrugs. Nov 28 10:50:57 i'd by now make a summary of your time wasted on that and present it to your supervisor. and get an absolutely explicit "ok, we're gonna waste lots of time there, but we totally want it, you're covered, and its not your fault" Nov 28 10:51:25 I'll just hardcode the version... Nov 28 10:51:41 i mean, this won't be the last fun time with that. Nov 28 10:52:19 For sure Nov 28 10:52:30 can't you glob at the relevant place? Nov 28 10:52:52 I'l spare you the details of compiling this on android haha weeks of my life I'll never get back. Nov 28 10:54:41 Not sure... worth a shot (re glob) Nov 28 10:58:21 We already have the whole system working on RTI and Raspbian, so while we wait for the delivery of new hardware, I'm just trying to improve this hand-rolled Raspbian setup a bit. Nov 28 10:59:14 pepijndevos: i actually pitched a paper to a conf here, on why starting your iot development on raspi+raspbian is a stupid idea in the vast majority of cases :-P Nov 28 11:00:51 I'd love to share that with my supervisor haha Nov 28 11:01:25 pepijndevos: if they accept it, i'll share. its german, though. feel free to hire me for an english version :) Nov 28 11:01:30 s/iot/robots with rotating blades/ Nov 28 11:02:49 well its a iot conf, hence the concept. Nov 28 11:03:19 the core message actually should read like: "if you want a real product, do not start on a tinkering board using tinkering ways." Nov 28 11:14:06 LetoThe2nd: or if you're going to prototype on a tinker board, be aware that is the one to throw away Nov 28 11:14:18 nothing wrong with prototyping, learning, throwing away and starting again Nov 28 11:14:31 just be aware that is a valid plan and don't expect to go from tinker to production Nov 28 11:15:21 rburton: thats why its "if you want a product" Nov 28 11:15:42 its fine if you want a) fun b) a one-off thing c) a prototype... whatever Nov 28 11:15:50 but not, "a product" Nov 28 11:17:30 i'd like to see this presentation in english :) Nov 28 11:21:29 I'm kind of working on a demo/protoype... but someone might say, hey this seems to work, lets put it in production... which will make me sad. Nov 28 11:21:57 RP: overnight master passed selftest! Nov 28 11:22:06 so clearly you broke it more with next Nov 28 11:22:27 meanwhile my recipe complains it's installing some directory that I have no idea where it comes from Nov 28 11:23:02 rburton: overnight master only runs on selftest, "full" runs five Nov 28 11:23:05 one Nov 28 11:23:31 fake news Nov 28 11:24:01 rburton: gah, just dont, please ;-) Nov 28 11:24:28 well the cpio thing replicated on debian so we can't call it a suse thing Nov 28 11:24:48 rburton: and I ruled out files changing :/ Nov 28 11:25:01 oh how did you do that? Nov 28 11:25:23 rburton: also the bitbake not starting replicated and the logs don't so anything so the new debugging didn't help :( Nov 28 11:25:48 rburton: I replied on list, have a a hacky patch: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c5787a6ddbfd2c1acc0e33fa158c238e6145351e Nov 28 11:25:58 but it proves the files don't change Nov 28 11:26:26 you verified that code works right Nov 28 11:26:30 sorry for the halfway angry ML post, but that guy really is getting on my nerves. it was about time to vent. Nov 28 11:26:46 * rburton runs to list Nov 28 11:26:47 rburton: re presentation, throw money! Nov 28 11:27:06 rburton: patch has a foo.txt which shows it does Nov 28 11:27:09 hm actually, it would be interesting for an OE user summit. Nov 28 11:27:26 I'll read it in german Nov 28 11:28:24 RP: ah, yes. i like that code, tidy it up and submit. lovely sanity test for dirs which shouldn't change. Nov 28 11:29:00 LetoThe2nd: which list was this? I could do with something to cheer me up ;-) Nov 28 11:29:08 rburton: I wondered if we should make it a feature Nov 28 11:29:10 RP: i wonder if any of the machines that cpio is crashing on have abort catchers on that are harvesting the cpio segfaults Nov 28 11:29:15 the recipe that used to work is now going from bad to worse for some reason... like... how did I get so in my -dev package -.- Nov 28 11:29:22 RP: yocto general Nov 28 11:29:29 rburton: I sadly doubt the core would be preserved Nov 28 11:30:10 RP: my cheering up now: lunch. Nov 28 11:46:44 RP: so the new parallel sefltest Nov 28 11:46:56 RP: each test gets a new unique build directory right? Nov 28 11:52:35 rburton: each parallel process Nov 28 11:53:17 so there are N build dirs for the level of parallelism and they are reused Nov 28 11:53:26 rburton: correct Nov 28 11:53:41 rburton: just realised that watchdir patch is bust, its not recursive :/ Nov 28 11:54:13 race: you fix the test and i'll finish my directory churn hack! Nov 28 11:54:21 * RP did however just figure out the mystery runqemu duplicate log messages, something that has bugged me for a long time Nov 28 11:57:16 rburton: game on :) Nov 28 12:00:58 rburton: do_image does change files, nothing else showing up Nov 28 12:05:47 rburton: just needed an os.walk adding Nov 28 12:06:10 well i have a cpio erroring out because files disappeared or changed, but not segfaulting Nov 28 12:08:04 rburton: which is more what you'd expect Nov 28 12:08:59 rburton: am I right in thinking we use cpio from the host for this? Nov 28 12:09:09 i believe so Nov 28 12:10:01 cpio-native is required by testimage Nov 28 12:10:13 yeah was just looking there Nov 28 12:10:40 is that enabled during selftest though? Nov 28 12:12:35 I'm confused... Nov 28 12:12:37 -dev package contains non-symlink .so: dds-dev path '/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/dds/5.3.1-r1/packages-split/dds-dev/usr/lib/libnddscpp.so' Nov 28 12:13:01 rburton: It could have been installed by a previous test I guess Nov 28 12:13:33 pepijndevos: most likely because this software shipped unversioned libraries Nov 28 12:13:42 which is bad practise Nov 28 12:13:58 pepijndevos: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries Nov 28 12:14:28 oooh, I remember that. Yea, this things is bad practice stacked on bad practice haha Nov 28 12:17:32 RP: replicated on demand! Nov 28 12:17:37 yeah its cpio-native Nov 28 12:17:44 i wonder how we broke that! Nov 28 12:18:03 RP: can you reproduce please? do_image_cpio[depends] += "cpio-native:do_populate_sysroot" to image_types, add cpio to IMAGE_FSTYPES, build something Nov 28 12:18:26 i bet one of the cve patches we got actually broke cpio Nov 28 12:19:32 shall grab a second coffee and sort Nov 28 12:19:40 rburton: oddly enough I couldn't get that to crash here Nov 28 12:19:44 damnit Nov 28 12:19:54 ok well i made it crash once, lets try again Nov 28 12:19:59 and maybe i have a coredump to help Nov 28 12:20:20 rburton: I suspect its distro specific Nov 28 12:20:36 rburton: but anything reproducing is good Nov 28 12:21:12 rburton: I tried a couple of different ways and cpio-native works here (on ubuntu) Nov 28 12:21:20 weird Nov 28 12:22:03 rburton: certainly bitbake XXX-image -c testimage in an earlier test would have put it in the sysroot and it wouldn't get removed Nov 28 12:22:24 i wonder what the impact of a clean builddir per test will be :) Nov 28 12:23:53 rburton: huge amounts of sstate extraction Nov 28 12:24:09 well, yeah Nov 28 12:24:12 that's nice and fast :) Nov 28 12:25:40 breaking cpio would be an achievement Nov 28 12:28:21 yes Nov 28 12:28:41 Is there an easy way to figure out what to put in RDEPENDS to satisfy the QA errors I'm getting? Very common stuff like libc, libdl, libm, libstdc++ Nov 28 12:36:36 https://paste.ubuntu.com/p/myjNQcx9tw/ Nov 28 12:37:01 I added RDEPENDS_${PN} = "libstdc++", but nothing changes. Is this also a problem with versioned .so? Nov 28 12:40:47 pepijndevos: hm it should have found those for you Nov 28 12:41:11 RP: make it log more, stops segfaulting Nov 28 12:42:56 Mmmh how does one set ownership on a file during do_install ? I've tried using the user & group number (e.g `install -o 1000 -g 1000 -m 755 path/to/file) but file then shows up as owned by 0(root) Nov 28 12:43:36 guillaumekh: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb Nov 28 12:43:45 Oh... maybe I know... would it fail if the .so is not for the same architecture? Confession: because RTI disabled our Raspberry Pi target, I've been using the Android target for testing the basic recipe. Maybe this is where I actually just need the proper raspi files... Nov 28 12:44:40 pepijndevos: QA barfs if the arch does not match. not sure about the ABI, but i wouldn't rule it out. Nov 28 12:48:05 Another fun challenge down the road is that the rpi target is built with gcc 4.7 and C++11 so linking will break anyway until I solved that by either asking RTI for a new target, or changing yocto compiler flags or compiler version. Nov 28 12:48:17 Hi guys. I want to upgrade my layers to new versions (e.g. to new branch sumo).. But now I have an troubles, like: ERROR: Nothing PROVIDES 'libgal-imx' ... Close matches: Nov 28 12:48:18 libgxim Nov 28 12:48:18 imx-gpu-viv RPROVIDES libgal-imx ... A full log here: https://pastebin.com/s8DNhyUC Nov 28 12:48:29 How to solve this issue? Nov 28 12:50:01 kuzulis: find out why imx-gpu-viv is not buildable, by the looks of it. Nov 28 12:51:02 (yea, I hacked the recipe to copy my already installed Rpi target and that passes QA... so just keep begging RTI I guess) Nov 28 12:54:22 LetoThe2nd: Do I need to add this 'imx-gpu-viv' recipe e.g to IMAGE_INSTALL_append ? Nov 28 12:55:29 kuzulis: no, dependencies should pull it in. the question is, why isn't it buildable (thats how i interpret it) Nov 28 12:56:54 rburton: but you can reproduce the segv? Nov 28 12:57:18 New news from stackoverflow: How to flash Yocto Images directly using clonezilla Nov 28 12:58:11 LetoThe2nd: What commands I need to enter to search that? Nov 28 12:58:21 Aaaalmost there. My CMake project installs settings in etc, but these end up in /usr/etc and cause QA errors. Nov 28 13:02:51 RP: sometimes Nov 28 13:04:12 ah, solution: https://cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html Nov 28 13:04:21 pepijndevos: yes please use that Nov 28 13:05:45 LetoThe2nd: I have entered: bitbake-layers show-recipes | grep imx-gpu-viv and see that imx-gpu-viv is present.. Nov 28 13:06:31 kuzulis: look at the recipe if it has a COMPATIBLE_MACHINE or something like it Nov 28 13:07:36 LetoThe2nd: I see COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)" Nov 28 13:07:59 kuzulis: and do you have one of those? Nov 28 13:10:29 LetoThe2nd: I use apalis-imx6 Nov 28 13:10:57 kuzulis: well then, theres your answer. Nov 28 13:11:07 append it and add that to the compatible machines Nov 28 13:15:04 LetoThe2nd: Hmm.. but for previous layes version, same recipe 'imx-gpu-viv' contains similar COMPATIBLE_MACHINE = "(mx6q|mx6dl|mx6sx|mx6sl)" ... And it does work. Nov 28 13:17:26 LetoThe2nd: Where apalis-imx5.conf machine has following text: MACHINEOVERRIDES =. "mx6:mx6q:" Nov 28 13:17:52 LetoThe2nd: s/apalis-imx5/apalis-imx6 Nov 28 13:18:02 kuzulis: ok, at the point its beyond my knowledge, sorry. Nov 28 13:19:19 So, nobody can help ? :( Nov 28 13:40:59 kuzulis: the `OVERRIDES` variables describe which variables' priority. Read the documentation on it :) Nov 28 13:41:22 s/which// Nov 28 13:42:52 I have a few robots that have slightly different software. Should those be their own layer or just recipes and different images? Nov 28 13:42:54 kuzulis: then examine the output of `bitbake -e imx-gpu-viv`. Look at the evaluation of `COMPATIBLE_MACHINE`. Nov 28 13:44:44 pepijndevos: depends on how they differ. Devicetree? Kernel? Single Binaries? The way something is compiled? Image? Nov 28 13:47:25 T_UNIX: bitbake -e imx-gpu-viv | grep ^COMPATIBLE_MACHINE shows that it is: COMPATIBLE_MACHINE="(mx6q|mx6dl|mx6sx|mx6sl|mx7ulp)" Nov 28 13:48:35 T_UNIX, just one different package and its deps. One uses wiringpi, one something else. Nov 28 13:48:43 T_UNIX: That is correct for apalis-imx6, because apalis-imx6 is same as "mx6:mx6q:" Nov 28 13:50:37 rburton: was your intention (i.e.., with binconfig_xyz) that all crossscripts would be placed in the /usr/bin/crossscript folder and that folder would be in the path, and that the proper "version" of the script (whether cross build or target build) is placed in that folder for staging or packaging, respectively? Nov 28 13:50:52 kuzulis: and that matches the `PACKAGE-ARCHITECTURE` (cannot recall the precise variable name)? Nov 28 13:51:50 pepijndevos: if each software would technically be compatible with any machine, use a different image Nov 28 13:52:12 respectively Nov 28 13:52:26 T_UNIX: Where is PACKAGE-ARCHITECTURE ? Nov 28 13:53:17 kuzulis: In the package's recipe Nov 28 13:53:49 it's called `PACKAGE_ARCH` Nov 28 13:54:54 or did you intend to put relative symlinks to each script in /usr/bin, so that they work no matter where /usr/bin/crossscript is located, and the PATH can remain standard? Nov 28 13:55:22 or something else? ;) Nov 28 13:56:15 T_UNIX: There are no PACKAGE_ARCH, in that *.bb file Nov 28 13:58:10 T_UNIX: (nor in new layer branch, nor in previous layer branch) Nov 28 13:59:33 cool thanks Nov 28 13:59:50 kuzulis: examine the output of `bitbake -e imx-gpu-viv`. It could be in some `.inc`, some `.bbappend` or in some distribution/machine configuration. Nov 28 14:02:38 T_UNIX: bitbake -e imx-gpu-viv | grep PACKAGE-ARCH has an empty output Nov 28 14:03:04 T_UNIX: oops, sorry Nov 28 14:03:39 kuzulis: what does `bitbake imx-gpu-viv` complain about? Maybe examine the entire output instead of greping for partial words that might be incorrect? Nov 28 14:03:51 T_UNIX: PACKAGE_ARCH="cortexa9hf-neon-mx6qdl" Nov 28 14:03:51 PACKAGE_ARCHS="all any noarch armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp armv7at2hf-vfp armv7ahf-neon armv7at2hf-neon cortexa9hf-vfp cortexa9hf-neon cortexa9t2hf-vfp cortexa9t2hf-neon cortexa9hf-neon-mx6qdl cortexa9t2hf-neon-mx6qdl apalis_imx6" Nov 28 14:04:06 anyone? Nov 28 14:05:41 is the sysroot for a build under ${B}? Nov 28 14:05:50 is it known that gpgme does not build? (sumo) Nov 28 14:05:59 the configure script does not find libgpg-error Nov 28 14:06:41 derRichard: it definitely builds on the autobuilder Nov 28 14:07:11 RP: hmm. Nov 28 14:07:32 just tried with both arm and x86 targets Nov 28 14:07:50 derRichard: does the gpgme recipe have libgpg-error (or some recipe providing it) in its DEPENDS? Nov 28 14:08:04 yates: yes, it does. Nov 28 14:08:49 T_UNIX: Any other suggestions? :) Nov 28 14:09:25 as I said: `bitbake imx-gpu-viv` look why it fails. Does it fail? Nov 28 14:09:30 derRichard: What changes do you have on top of standard sumo? Nov 28 14:10:56 RP: just my layer. i didn't change gpgme at all Nov 28 14:11:47 let me read the config.og Nov 28 14:11:50 *config.log Nov 28 14:12:08 maybe the configure script is just stupid and the root cause is something different Nov 28 14:12:50 derRichard: we do disable a lot of the gnupg -config scripts and differ from upstream there but it should autoreconf and handle that, we do test it on the autobuilders Nov 28 14:13:57 configure:22254: $PKG_CONFIG --exists --print-errors "gpg-error >= $min_gpg_error_version" Nov 28 14:14:00 Requested 'gpg-error >= 1.24' but version of gpg-error is 1.18 Nov 28 14:14:01 now things get interesting Nov 28 14:14:40 hmm, makes no sense Nov 28 14:14:47 * derRichard checks layers again Nov 28 14:16:43 meh, somebody copied an old gpg-error recipe into the customer's layer Nov 28 14:16:49 yates: it depends on yocto version. for morty, it is not, it is under ${TMPDIR}/sysroots Nov 28 14:20:58 derRichard: that would explain it Nov 28 14:21:34 RP: yes :-( Nov 28 14:21:41 * derRichard needs to review that layer Nov 28 14:36:00 T_UNIX: > `bitbake imx-gpu-viv` look why it fails. Does it fail? Nov 28 14:36:10 T_UNIX: It compiles successfully Nov 28 14:36:57 T_UNIX: It fails only then I build image: Nov 28 14:36:59 ERROR: Nothing PROVIDES 'libgal-imx' (but /mnt/data/Yocto-miatech/yocto-miatech/sources/meta-freescale/recipes-graphics/xorg-driver/xf86-video-imx-vivante_6.2.4.p1.2.bb DEPENDS on or otherwise requires it). Close matches: Nov 28 14:36:59 libgxim Nov 28 14:36:59 imx-gpu-viv RPROVIDES libgal-imx Nov 28 14:37:04 wtf? Nov 28 14:37:28 kuzulis: PROVIDES != RPROVIDES Nov 28 14:37:33 RPROVIDES vs. PROVIDES Nov 28 14:37:44 kuzulis: sounds like somewhere the dependency structure was modified Nov 28 14:37:45 R(UNTIME)PROVIDES vs PROVIDES Nov 28 14:39:07 and? what I need to do here? :) Nov 28 14:39:22 I did not change anything Nov 28 14:39:57 I just update a layers from pyro to sumo Nov 28 14:40:04 kuzulis: if i had to guess, then i'd say that you only updated one or a couple of your layers in use, but not all of them Nov 28 14:42:10 LetoThe2nd: I have updated all layers, exclude qt4/5 layers: https://pastebin.com/5a9mF36B Nov 28 14:44:25 kuzulis: heh its nice that you show such detailed information, but i actually do not know by just looking at git commit hashes which states of the layers those are. Nov 28 14:46:32 LetoThe2nd: I taked this hashes from: http://code.qt.io/cgit/yocto/meta-boot2qt.git/tree/scripts/manifest.xml?h=sumo Nov 28 14:47:06 LetoThe2nd: I hope that that a true hashes :) Nov 28 14:48:58 kuzulis: sorry, i'll actually not dig there further. i'm just saying, something obviously first DEPENDED in it, and it PROVIDES. thats ok. now it changed from PROVIDES to RPROVIDES, but the recipe that DEPENDed did not change. so, thats where you have to go hunting. Nov 28 14:53:29 LetoThe2nd: Ohhh.. many thanks, anyway :( Nov 28 14:55:19 LetoThe2nd: Then, is any workariunds for this, witchout of modifing os a source layers (not my layers)? Nov 28 14:55:55 kuzulis: that would be then reporting to upstream. Nov 28 14:59:04 LetoThe2nd: Nono, I mean, is it possible to fix it without of modifing of a provided (not my) layers? Nov 28 14:59:24 LetoThe2nd: to do not touch that layers? Nov 28 14:59:28 kuzulis: can definitively say. but probably no. Nov 28 15:00:05 s/can/can't/ Nov 28 15:05:16 LetoThe2nd: I see in latest imx-gpu-viv*.inc file this: Nov 28 15:05:26 PROVIDES += " \ Nov 28 15:05:26 imx-gpu-viv \ Nov 28 15:05:43 and: Nov 28 15:05:44 RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" Nov 28 15:09:30 LetoThe2nd: Ahh, sorry, I see: RPROVIDES_libgal-imx += "libgal-imx" Nov 28 15:11:37 LetoThe2nd: but when I see to previous 'imx-gpu-viv*.inc' file, then there are no any mentions of 'libgal-imx' Nov 28 15:16:53 LetoThe2nd: Hmm... no... I'm confused.. I see that a newest 'imx-gpu-viv*.inc' file contains: PROVIDES += " \ Nov 28 15:16:53 imx-gpu-viv \ Nov 28 15:16:53 libgal-imx \ Nov 28 15:17:17 but why bitbake say that " Nothing PROVIDES 'libgal-imx' " ? Nov 28 15:20:51 LetoThe2nd: Also this file contains and: RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" Nov 28 15:21:07 LetoThe2nd: So, maybe I need to remove this RPROVIDES_${PN}_imxgpu3d += "imx-gpu-viv" ? Nov 28 15:35:28 i'm baffled Nov 28 15:41:57 nm, ok, i'm good Nov 28 15:44:23 Yeaaah. Linking errors due to ABI changes in C++11 between gcc 4.x and 5.x. Until RTI comes up with a newer target, my options are basically: make everything that depends on RTI use _GLIBCXX_USE_CXX11_ABI or compile them with gcc 4.x Nov 28 15:48:40 Will poky be fine if I just do GCCVERSION="4.7.%" in local.conf or is that too ancient? And is there an easy way to pass _GLIBCXX_USE_CXX11_ABI from the (cmake) recipe? Nov 28 15:49:20 pepijndevos: it will do, if a recipe actually provides that version Nov 28 15:51:55 Seems like poky itself only has 8.2 and 7.3. Neeever mind then. I'll go the _GLIBCXX_USE_CXX11_ABI route. Or just do nothing and wait for RTI, they already told me that they have a newer target, they just haven't given it to me yet. Nov 28 15:54:06 why does specifying the -pthread option to a gcc link error out? Nov 28 15:54:43 https://paste.fedoraproject.org/paste/1nFOMkt0yTNc3ziqNJ8enQ Nov 28 15:55:41 correction: a g++ link Nov 28 15:55:41 well, something looks messed up because it's looking in the wrong path Nov 28 15:56:45 if i omit the -pthread option and just use -lpthread, it works fine Nov 28 15:57:07 could be a toolchain problem Nov 28 15:57:57 New news from stackoverflow: am335x evmsk screen init:id"00" respawning too fast disabled for 5 minutes yocto sumo Nov 28 16:20:30 right. thanks georgem Nov 28 16:48:25 what is the difference between the sysroot-destdir, build, and image subdirectories under /tmp/work//${PN}/${PV}-${PR} ? Nov 28 16:49:14 obviously build is when building the recipe. what about the others Nov 28 16:50:39 at what stage in the build process are the others used? Nov 28 16:50:44 rburton: I sent some patches to the python manifest to add comments last week, is there a reason why they haven't been merged yet?, I havent seen them in your contrib branches either, thats why I ask Nov 28 17:05:47 damn. `COPY_LIC_DIRS`. somhow broke when I removed a package that used to be a PREFERRED_PROVIDER. For some reason bitbake still wants to handle its license :-/ Nov 28 17:08:26 I mean I even `BBMASK`ed the file/package that is now apparently - according to `license.bbclass`' `license_create_manifest`- missing. Nov 28 17:16:58 it somehow comes up witht that via `runtime-reverse/$NOLONGEREXISTINGPACKAGE` Nov 28 17:22:26 aehs29: probably forgot to tag them Nov 28 17:22:29 aehs29: will sort Nov 28 17:22:43 yates: image is used when building a package too Nov 28 17:22:53 yates: build/ is the build tree for out-of-tree buids Nov 28 17:23:04 yates: image/ is where install installs too Nov 28 17:23:14 sysroot-destdir is the bits from image that are for the sysroot Nov 28 17:23:24 then there's package/ which is the bits from image for the packages Nov 28 17:23:31 and then packages-split which is package, but split per-package Nov 28 17:23:53 (grep can tell you this if you search for ${WORKDIR}/image, etc) Nov 28 17:23:59 over meta/classes/ Nov 28 17:26:18 where does that `ipk/` package management get its information from? How does it build its store? Nov 28 17:30:37 that was the culprit: obsolete packages in `deploy/ipk` lead to them retroactively corrupting the build Nov 28 18:08:27 i can see a library (namely, libwx_gtk2u_aui-3.0-arm-fslc-linux-gnueabi.so) under /tmp/sysroots//usr/lib, but my link is not finding ti Nov 28 18:09:06 | /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find -lwx_gtk2u_aui-3.0-arm-fslc-linux-gnueab Nov 28 18:09:36 do i need a special -L? Nov 28 18:10:19 ah, ok, thanks rburton Nov 28 18:24:49 Hi. I have created a custom layer, and created a bbappends file that points to a configuration fragment (at least according to my understanding). In my case the configuration fragment only contains one line: "CONFIG_TUN=y". Is there a way to check that the build successfully added this line to the kernel config without actually flashing the image to a real board (since I do not have the hardware where I currently am)? Nov 28 18:31:21 JSwede: what do you mean by "points to" Nov 28 18:31:43 in general, if a recipe DEPENDS on a library, will the link (ld) command for the recipe need to specify a special path to the library via a -L option? Nov 28 18:31:57 JSwede: easiest way would probably be to check the kernel build directory and open the .config, if the config is there, then youre golden Nov 28 18:32:31 JSwede: just fyi if its not there it does not necessarily mean that your bbappend isnt "pointing" to it correctly, there could be dependency issues or something Nov 28 18:33:06 yates: the linker should be able to pick them up automatically Nov 28 18:33:41 JSwede: what aehs29 said. so that your files are kept after building, it may be helpful to use devtool Nov 28 18:34:07 aehs29: ok, well it's not! :( Nov 28 18:35:02 i think i know why though Nov 28 18:35:12 yates: ideally, it should Nov 28 18:35:26 i'm specifying a -sysroot in my link command Nov 28 18:36:06 yates: well that would change where the linker is looking for it, the -sysroot parameter should also be populated automaticlaly Nov 28 18:36:09 aehs29: If I look in workspace//tmp/work//// the config file is there and it contains CONFIG_TUN=y just as it should. Then I guess I'm all set :) Thanks! Nov 28 18:37:40 JSwede: I think youre still missing a directory "linux-build-something", the .config file should be in there Nov 28 18:37:57 JSwede: just make sure youre looking at the final .config Nov 28 18:38:44 aehs29: ... Ah, maybe I misunderstood. I am not looking at a complete .config file. And now the server was shut down for me so I can't check anything else today. I will give it another shot tomorrow. Nov 28 18:39:42 yates: addind --verbose to the ld command should help you figuring out where its looking for the libraries Nov 28 18:40:03 JSwede: sure, but yes, it should be a complete .config Nov 28 18:41:00 aehs29: thanks, then I won't have to sit idle tomorrow :) Nov 28 19:10:51 when does yocto build the cross-toolchain? does it happen automatically when the first recipe is built? Nov 28 19:18:56 yates: yes Nov 28 19:19:09 ok, and where does that toolchain reside? Nov 28 19:20:12 yates: yes, the native and cross toolchain tasks are executed by the runqueue before due to their dependencies, and they reside in the sysroot Nov 28 19:20:14 from the overivew and concepts manual, section 2.7: During a build process, the build system tracks dependencies and performs a native or cross-compilation of the package. As a first step in a cross-build setup, the framework attempts to create a cross-compiler toolchain (i.e. Extensible SDK) suited for the target platform. Nov 28 19:20:41 aehs29: ok, thanks Nov 28 19:28:11 aehs29: is the proper sysroot specified via the environment variable SYSROOT? Nov 28 19:29:31 i'm using my own custom makefiles and am getitng wrapped around the axle a bit here Nov 28 19:31:42 yates: 'first recipe' isn't relevant, it's all based on dependencies. base.bbclass specifies the defualt deps on the cross toolchain via BASEDEPENDS, unless opted out with INHIBIT_DEFAULT_DEPS or inheriting a class that does the same, like native Nov 28 19:47:36 yates: I think thats probably why you're having issues with the --sysroot parameter to gcc, the Makefile needs to use what it gets from the build system, you can look at the variables such as CC , CFLAGS or LDFLAGS if you open the run.do_compile script inside the temp directory which is inside the work directory for your recipe, if you look at CC for example it already should have a --sysroot parameter Nov 28 20:01:04 khem: Thanks for your suggestion about hostame for determining MACHINE at image runtime! One more robust solution that I could think of is to create a recipe that adds the value of MACHINE to a file in the rootfs, such as /etc/machine/ Nov 28 20:02:11 I think /etc/os-release might be for it Nov 28 20:35:17 rburton: i see in the wx-config script where your binconfig_package_preprocess() performed this substitution: -e 's:${STAGING_LIBDIR}:${libdir}:g;' Nov 28 20:36:22 this was the on a line in wx-config that issued a -L when generating library configuration info Nov 28 20:37:37 nm. i thought it was creating an error there, but i think not. Nov 28 20:38:14 well, let me continue.. Nov 28 20:39:11 with that -L${libdir}, a subsequent recipe build that DEPENDS on wxwidgets errors out at the link stage: | /opt/fslc-x11/2.4.1/sysroots/x86_64-fslcsdk-linux/usr/libexec/arm-fslc-linux-gnueabi/gcc/arm-fslc-linux-gnueabi/7.2.0/real-ld: cannot find /lib/libpthread.so.0 Nov 28 20:40:10 -L${libdir} in a target recipe is going to lead to pain, as that'll reference files on the host. it's also just plain redundant, as that's in the default search path Nov 28 20:40:12 just drop it entirely Nov 28 20:40:35 kergoth: already tried that Nov 28 20:40:51 and this sort of thing is precisely the type of pain rburton warned you you'd run into trying to use a -config script, and is why binconfig.bbclass exists Nov 28 20:40:55 :) Nov 28 20:41:13 well i have to deal with it someway. Nov 28 20:41:52 if i remove the -L, several the libraries wxwidgets DEPENDS on are not found Nov 28 20:43:39 speaking of just the compiler/linker operation, shouldn't a "-L" _append_ the path to the existing search paths/ Nov 28 20:43:50 ? Nov 28 20:44:58 another unrelated recipe i wrote also issues a -lpthread and it gets resolved just fine. works. Nov 28 20:45:36 so the sdk has the pthread library, why isn't it finding it with a -L? Nov 28 20:46:34 if the -lpthread occurs AFTER the -L, does that limit the compiler to search for it JUST IN THAT ? Nov 28 20:46:40 that's what it's acting like. Nov 28 20:47:44 kergoth: i am using the binconfig.bbclass. i'm not sure if you were intimating i disabled it. Nov 28 20:48:21 no, it doesn't, but pthread is special. /usr/lib/libpthread.so, iirc, is generally a linker script Nov 28 20:48:34 if it loads the host one, it'll go directly to /lib rather than a path relative to the location of the .so Nov 28 20:53:10 kergoth: i don't understand your point. special or not, if one of my recipes with a -lpthread works, why wouldn't this one? Nov 28 20:53:45 I just told you, if /usr/lib is in the search path, it'll grab the .so from there first and break Nov 28 20:53:57 it doesn't limit to only that path, but the result is the same, as it grabs the first one it finds Nov 28 20:54:11 you can't include host paths in the library esarch path when crosscompiling Nov 28 20:54:43 why would /usr/lib be in the search path? Nov 28 20:55:56 i don't understand the question. Nov 28 20:56:29 libdir by definition is the path in the target rootfs where the libs get installed. in non-native recipes, that's ${prefix}/lib, aka /usr/lib Nov 28 20:56:39 * kergoth shrugs, gets back to work Nov 28 20:57:22 kergoth: you said "if /usr/lib is in the search path". so i asked why would that happen? in a cross build, you should be using another sysroot, right? Nov 28 20:58:42 more specifically, why would the search path in one of my recipes NOT contain /usr/lib, yet another recipe DOES contain /usr/lib. when the recipes are structured the same with the exception of this -L? Nov 28 20:58:43 no, —sysroot affects default paths only, you can specify -I/-L paths to be relative to sysroot by prefixing with =, otherise they're interpreted as absolute paths, not paths relative to the sysroot. Nov 28 20:58:44 see also https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html Nov 28 20:58:50 afaik, anyway Nov 28 20:59:04 ok, let me check that. Nov 28 20:59:33 both recipes contain a -lpthread Nov 28 21:00:00 -L/usr/lib is referencing a host path, not a path relative to the sysroot, and the host's libpthread.so hasn't been fixed up the way ours has Nov 28 21:01:01 but that's not where my -L is pointing: -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib Nov 28 21:01:01 that's the most likely cause, anyway, as far as I can tell. could be missing something, but i'd eliminate that before digging elsewhere Nov 28 21:02:07 then something has adjusted it back to STAGING_LIBDIR, don't see a problem with that, but if ithat's the case i'd check the actual libpthread.so it's linking against to ensure it's sane Nov 28 21:03:17 good idea Nov 28 21:04:48 if it's trying to link to /lib/libpthread, it's probably a hosted linker script unless something else is going on. could add -v to the linker commandline perhaps? Nov 28 21:04:55 and just cat the libpthread.so Nov 28 21:05:31 good ideas, thanks. i will. Nov 28 21:10:58 np, good luck with it, sounds like it's an awfully painful recipe Nov 28 21:11:17 you can say that again. thanks! Nov 28 21:31:26 i can see a little further what's happening: there is a libpthread.so script at -L/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart/usr/lib Nov 28 21:31:34 https://paste.fedoraproject.org/paste/LI-ei~mMFcTc5E-yJ2V0TQ Nov 28 21:31:54 it's apparently the two paths specified in that GROUP that are causing the error Nov 28 22:35:26 khem: Ahh i see! So I'll probably bbappend the os-release recipe to add MACHINE. Do you think this would be an addition that Nov 28 22:36:13 Do you think that this would be an addition worth submitting a patch for? Nov 28 22:43:48 I am not sure Nov 28 22:51:24 robbawebba: I think the image-buildinfo class does something similar Nov 28 22:51:40 just saying thats another option Nov 28 23:30:57 aehs29: ahh, nice suggestion. I'll take a look at both. Nov 29 02:29:59 New news from stackoverflow: bitbake error when remove wayland in local.conf on Ubuntu 14.04 **** ENDING LOGGING AT Thu Nov 29 02:59:59 2018