**** BEGIN LOGGING AT Thu Oct 13 02:59:59 2016 Oct 13 14:22:25 i'm still struggling with trying to package files made with "make install" as a result of a cmake build. Oct 13 14:22:29 https://gist.github.com/netskink/2cd7f2464a4ccc95fb5c3c771ea0a9d7 Oct 13 14:22:50 I'm specifying the make install location in the recipe shown above Oct 13 14:23:14 I'm also showing the various attempts at results. Oct 13 14:23:36 As it is now, my receipe for the package works, but the build of the image fails. Oct 13 14:32:54 davis: if you have a "make install" that works, and you use cmake, then you don't need to do anything inthe recipe Oct 13 14:33:28 yes, so in my recipe I do make install and it appears to work Oct 13 14:33:42 however, when I build my image and boot it Oct 13 14:34:03 the only thing there is the empty dirs, the actual dirs which have files in them are missing. Oct 13 14:34:30 so I thought I needed to include the files in the package to get them to the final image. Oct 13 14:34:47 go into your work directory and verify that its actually installing the files properl Oct 13 14:34:48 y Oct 13 14:34:54 ok one sec Oct 13 14:35:11 the image/ directory is where make install would install into Oct 13 14:37:02 the image dir as it is now, does not have the dirs with files in them Oct 13 14:37:16 so we've conclused that your make install logic is broken Oct 13 14:37:21 fix your cmake files Oct 13 14:37:34 hmm. Oct 13 14:37:46 what is odd, if I do this standalone it works Oct 13 14:37:53 if you have a working "make install" with cmake then you don't need *any* do_install in your recipe Oct 13 14:38:10 good Oct 13 14:38:36 its possible that you have broken relocation, i.e. where we do make install DESTDIR=$D Oct 13 14:38:48 if destdir support is broken, files can go to the wrong place. Oct 13 14:40:11 in my log.do_package it says for one of tghe files Oct 13 14:40:16 /home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/pcmx/1.0.0+gitAUTOINC+d3_d3v16_pcmx-r0/image/usr/bin/pcmx/lfo/d3comm.lfo Oct 13 14:40:39 so there it says image/usr/bin/pcmx/lfo/d3comm.lfo is in the proper place Oct 13 14:40:44 but when I look in Oct 13 14:41:24 the dir its specifying, ie. ~/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/pcmx/1.0.0+gitAUTOINC+d3_d3v16_pcmx-r0/image Oct 13 14:41:31 it does not have it Oct 13 14:41:53 but i see the problem Oct 13 14:42:06 it has in image, home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/pcmx/1.0.0+gitAUTOINC+d3_d3v16_pcmx-r0/image/usr/bin/pcmx/ Oct 13 14:42:40 this must be wrong Oct 13 14:42:53 sounds like your cmakelists is buggy Oct 13 14:42:56 EXTRA_OECMAKE_class-target = " -DBITBAKE_BUILD_MODE=target -DNT_INSTALL_DIR=${D}${bindir}/pcmx/" Oct 13 14:43:27 dont pass ${D} Oct 13 14:43:29 if I did -DNT_INSTALL_DIR=${bindir} it was trying to install to /usr/bin on my build box / Oct 13 14:43:47 that would be because you were not passing DESTDIR=$D in your make install, or your cmakelists is broken Oct 13 14:44:24 "i'm trying to think but its not working" Oct 13 14:45:09 the cmake uses that -DNT_INSTALL_DIR to specify where to install Oct 13 14:45:29 and its a fully qualified path Oct 13 14:47:51 so the cmake is built during do_configure(), but druing bitbake do_install() it passes in a DESTDIR? Oct 13 14:52:23 yes, have a look at cmake.bbclass Oct 13 14:55:57 many thanks, I've got one of the files installing in the right place if I do Oct 13 14:56:01 make DESTDIR=/tmp/usr/bin install Oct 13 14:56:27 this means that bitbake is doing this type of mechanism during its make install Oct 13 14:56:42 i figured it was just doing make install Oct 13 14:57:13 it is, mostly. DESTDIR is standard "install it here instead as i'm building a package" practise Oct 13 14:57:37 *everything* using cmake and *everything* using autoconf uses make install DESTDIR=${D} Oct 13 15:02:13 s/autoconf/automake/, technically Oct 13 15:02:25 there are autoconf based systems not using automake that don't follow the automake DESTDIR convention Oct 13 15:02:29 but mostly yes :) Oct 13 15:03:46 kergoth: yeah, pedantry accepted Oct 13 15:03:52 hehe Oct 13 15:05:58 hmm. it never ends. Oct 13 15:06:50 so removing all instances of the custom install prefix and just relying on make DESTDIR=/tmp/foo install works for all the binaries Oct 13 15:07:22 that works for all the paths determined when I do the installs of files Oct 13 15:08:24 but where I need some dirs in place, I was using cmake to figure that out via another mechnism and that is determined when the cmake makes the makefiles and not during the make install Oct 13 15:08:32 i'll need to figure that out Oct 13 15:31:52 From what i understand yocto is automatically building a release version and a debug version of my (CMake based) repo. Is there also a log.do_compile_debug etc. log where the output of the debug build is logged? Oct 13 15:37:10 that's not true Oct 13 15:37:44 cmake.bbclass doesn't do anything in particular for debug vs release Oct 13 15:39:53 rburton: But how come i've got a binary in <...>/packages-split/-dbg/path/in/rootfs/.debug/ then? Oct 13 15:40:06 (which is not stripped btw) Oct 13 15:40:35 because we take the unstripped binaries that "make install" installs, then extract the debug symbols and put them there Oct 13 15:40:55 so contains stripped binaries, and -dbg is the debug info Oct 13 15:41:00 (as every other linux distro does) Oct 13 15:41:46 Ah, i thought it was just build with CMAKE_BUILD_TYPE=Debug Oct 13 16:07:07 pushed minor fix for pseudo's configure to handle cflags that include commas. Oct 13 16:08:00 seebs: did you close the bug? Oct 13 16:10:44 not yet, I just pushed the fix to pseudo upstream. I haven't got a working yocto tree handy right now. Oct 13 16:10:59 I'm still trying to get to the pseudo bug fixes, but I haven't had as much time for doing yocto patches. Oct 13 16:11:30 I have a couple of moderately large and intrusive changes I want to make at some point, I figured out where at least one possible hole is that could be causing reduced reliability. Oct 13 16:13:17 well if its filed in pseudo then i'd say you can close the bug Oct 13 16:13:43 Oh, I see. It's not affecting oe-core, it's just affecting pseudo. Oct 13 16:19:29 now that morty is branched, are patches bound for master/2.3 being queued yet, or are we still focused on predominently on the bugfixing for morty? Oct 13 16:20:56 kergoth: personally everyone in intel is swearing at morty to get a stable build Oct 13 16:21:14 hehe, fair enough Oct 13 16:21:16 i've been tagging patches in my queue for post-morty Oct 13 16:46:58 so, you can't use an nfsroot with runqemu unless rootfs.pseudo exists, which is only the case if you ran runqemu-extract-sdk to set up the nfsroot Oct 13 16:47:07 but i'm using runqemu in a normal build context, no sdk involved Oct 13 16:47:14 if that script is required to extract any rootfs, it should be named that way. Oct 13 17:26:33 so in cmake, if I don't specify install dirs without a leading / it will add a /usr/local/ prefix Oct 13 17:27:12 so now when I do this in bitbake, since I'm not specifying a ${D} anywyere, its putting everything in / Oct 13 17:58:01 rock and roll! finally Oct 13 18:08:22 davis: that sounds like a bug in the cmakelists (the /usr/local thing) Oct 13 18:13:10 Hmm Oct 13 18:13:22 no sigbasedata was written out for my task. what would cause a task to be missing from that.. Oct 13 18:13:32 it wrote it for devshell, etc, but not the task i added in the recipe Oct 13 18:13:34 weird Oct 13 18:53:22 kergoth: i think if you specify relative destination dirs for install() in cmake, it by default puts them in /usr/local Oct 13 18:54:28 lol, omg it never ends Oct 13 18:54:45 so before I had just my dirs which were empty in my /usr/bin/pcmx Oct 13 18:55:04 lol, now I just have the dirs with files in them. The empty ones are not there. rofl Oct 13 18:55:26 If you specify relative destination dirs it puts the files in CMAKE_INSTALL_PREFIX, which is correct Oct 13 18:56:10 So unless you aren't used cmake.bbclass (and thus not passing CMAKE_INSTALL_PREFIX), you should be fine Oct 13 18:56:31 i got another problem. even though I specify the DBG symbols, and my cmake has a -g entry, I don't get debug symbols. Oct 13 18:57:04 Debug symbols are automatically separted into a ${PN}-dbg package by Yocto Oct 13 18:57:15 So this is not a bug, but a feature. Oct 13 18:57:28 my ...../image dir has the empty dirs Oct 13 18:57:42 neverpanic: genau Oct 13 18:58:05 i tried to add them to my pcmx-dbg package, at lest that it was i think i was doing Oct 13 18:58:17 PACKAGES = "${PN}-dbg ${PN}" Oct 13 18:58:23 i have that in my recipe Oct 13 19:01:26 you shouldn't be overriding PACKAGES Oct 13 19:01:32 let it package it properly automatically Oct 13 19:01:40 i'm trying something else, when this completes i'll let you know. Oct 13 19:13:51 hmm. ok so now all my files and directories, even the empty ones are there Oct 13 19:14:00 but the debug symbols are not Oct 13 19:14:21 i guess I need to include pcmx-dbg as a layer in my image? Oct 13 19:19:03 images do not consist of layers Oct 13 19:19:11 images consist of packages Oct 13 19:34:35 davis: if you want debug symbols in your image the easy solution is to add dbg-pkgs to IMAGE_FEATURES. that will add all dbg packages, so your code has symbols for stuff it calls into (like libc) Oct 13 19:47:08 rburton: yes, lol i came here to say i'm very happy i got the symbols in the target Oct 13 19:47:23 i did exactly that, I put pcmx-dbg in my image recipe Oct 13 19:47:31 but here is the twist Oct 13 19:47:58 when I remote gdb, my host box says it cant find the source. Its looking for source in /usr/src/debug/pcmx Oct 13 19:48:15 the simple answer is just ln -sf mysrc dir to /usr/src/debug/pcmx Oct 13 19:48:54 if you're using remote gdb then you don't need symbols on the target of course Oct 13 19:49:02 ineddee Oct 13 19:49:05 indeed Oct 13 19:49:07 there's a more comprehensive solution to remote gdb in the documentation Oct 13 19:49:16 you can build a shadow rootfs that is all debug symbols, and point gdb at that Oct 13 19:49:27 so you get the right symbols for all your binaries Oct 13 19:49:47 the newish debug filesystem support would be ideal for that, it does exactly that Oct 13 19:49:53 debug image, that is Oct 13 19:51:00 yeah newish Oct 13 19:51:07 depends how old your system is Oct 13 19:51:26 IMAGE_GEN_DEBUGFS = "1" Oct 13 19:51:36 had to grep the docs, couldn't remember the name of the thing Oct 13 19:51:38 heh Oct 13 19:52:25 http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#platdev-gdb-remotedebug Oct 13 19:52:27 cool Oct 13 19:52:32 many thanks **** ENDING LOGGING AT Fri Oct 14 02:59:58 2016