**** BEGIN LOGGING AT Wed Jun 10 02:59:59 2015 Jun 10 14:44:43 Hmm Jun 10 14:45:24 If FILES_${PN} references the locations on the target, how can I use that to specify my packages? Jun 10 14:46:00 To specify what goes in my packages? Jun 10 14:46:28 As in, say I put a lib in ${D}/usr/lib Jun 10 14:47:14 Does that mean that it should be FILES_${PN} += "/usr/lib/libwhatever.so" Jun 10 14:48:35 And the package step will pick that up automatically? Hmm, nevermind, I guess it must. Jun 10 14:48:56 And that's why I get the "installed but not shipped" step and it references it as /usr/lib/libwhatever.so Jun 10 14:55:34 pumpernickel: that's correct... except /usr/lib/ is already picked up by the default FILES_${PN}... Jun 10 14:55:56 Hmm, so I'm not sure what I'm doing wrong. Jun 10 14:56:27 I'm starting believe I'm on a different branch than I thought I was... Jun 10 14:57:17 When I checked the manual for the FILES_${PN}, it made reference to the variables in bitbake.conf having bindir and libdir, but I actually don't see them in mine. Jun 10 14:57:32 which bitbake.conf are you looking at? Jun 10 14:57:46 sources/bitbake/conf/bitbake.conf Jun 10 14:57:58 I guess I see now that there's a separate one in openembedded-core. Jun 10 14:58:33 that's not the one to be looking at, the one in OE-Core is the one that is getting used Jun 10 14:58:41 bitbake's one is just an example Jun 10 15:00:21 if you're not sure what's going on, remember you can actually look in ${D} - it's the image/ subdirectory under the workdir for the recipe Jun 10 17:21:44 bluelightning: thank you for your help Jun 10 17:25:57 Here is my bitbake recipe (I've actually removed the FILES_${PN} line, but I'm still having trouble. Jun 10 17:25:57 http://pastebin.com/DmAhEqJ4 Jun 10 17:26:06 Does anyone see any obvious errors with this? Jun 10 17:26:35 The DESTDIR variable passed in the do_install can be thought of as prefix. Jun 10 17:28:06 The makefile essentially installs to $DESTDIR/usr/lib Jun 10 17:29:18 If I manually run bitbake -c install recipe_name.bb, the files appear in the image/ directory as expected. Jun 10 17:29:53 It does not seem to appear properly in my output image. Jun 10 17:30:49 pumpernickel: if you are receiving warnings about files being installed but not shipped then that is not surprising, because if those files are not packaged then they can never get into the final image Jun 10 17:30:53 At the moment, I'm really just trying to figure out if my externalsrc recipe is fine, or I messed up my image recipe. Jun 10 17:31:40 Any library in ${D}/usr/lib/*.so should automatically be grabbed though, shouldn't it? Jun 10 17:32:02 Or does it have to be in ${D} directly, and not a subdirectory? Jun 10 17:32:31 if you look in meta/conf/bitbake.conf you will see the default value of FILES_${PN} Jun 10 17:33:02 as far as /usr/lib is concerned the relevant item in the default value is ${libdir}/lib*${SOLIBS} Jun 10 17:33:23 SOLIBS is ".so.*" Jun 10 17:33:35 this is set up to support versioned libraries Jun 10 17:34:29 if you are not using versioning for your libraries then the default FILES_${PN} value will not pick up your libraries Jun 10 17:34:49 Oh, I should have known when I saw that. Jun 10 17:34:50 in which case you will need to add to FILES_${PN} Jun 10 17:34:57 That it was not regular expression, but globbing. Jun 10 17:35:01 right yes Jun 10 17:35:57 So if I do have that FILES_${PN} line, it should be "/usr/lib/libTestlib.so", correct? Jun 10 17:36:04 Since that is the path it should be on the target. Jun 10 17:36:24 yes Jun 10 17:36:29 that file isn't a symlink right? Jun 10 17:36:35 No, it is not. Jun 10 17:36:37 ok good Jun 10 17:36:59 I know policy usually has that pointing to a specific version of a lib. Jun 10 17:37:11 you can use ${libdir} instead of /usr/lib but that's not going to make any difference to whether it works or not Jun 10 17:37:25 I used to have version numbers in the recipes, but since this will all be externalsrc and constantly changing, I decided to bake that into the autogenerated portion. Jun 10 17:37:50 Yeah, I would rather do that, because I do prefer to use the proper abstractions. Jun 10 17:38:41 Which is why I probably also update my makefiles to use prefix for the installation path instead of destdir. Jun 10 17:39:09 I probably should* also update... Jun 10 17:39:26 so, the other problem you will probably hit now is that that .so file will probably end up in the ${PN}-dev package even if you add it to FILES_${PN} Jun 10 17:41:21 the reason being, the system looks through the packages in the order they appear in the value of PACKAGES, and the first package whose FILES value matches a file, gets the file Jun 10 17:41:40 and ${PN}-dev comes before ${PN} in the default value of PACKAGES Jun 10 17:43:14 I'm thinking more and more I should have tried a build with yocto 1.8 just so I could see how their devtool generates externalsrc recipes. heh Jun 10 17:43:31 Seems like externalsrc recipes are kind of difficult to get right. Jun 10 17:44:03 What is the solution to that issue? How do I make sure it's not owned by the dev package? Jun 10 17:45:56 devtool wouldn't have helped you with this part, it doesn't concern itself with packaging at all atm Jun 10 17:46:07 (I wrote most of devtool, FYI) Jun 10 17:46:38 haha, that's funny. I should have known! You are very knowledgeable on the inner workings. Jun 10 17:46:52 probably change the value of FILES_${PN}-dev so it doesn't point to that file Jun 10 17:47:51 Should that point to the .debug directory? Jun 10 17:48:29 I'll just null it out for now I suppose. Jun 10 17:51:33 well the .debug directory goes into the -dbg package, it probably already is going there Jun 10 17:56:16 I suppose the mistake I'm making here is that externalsrc recipes might not even be intended to create packages? Jun 10 17:56:36 And that when you want to create packages, it should probably be a more typical make-package with a src-uri? Jun 10 17:56:39 Is that where I'm failing? Jun 10 17:57:21 I can kind of see the logic in that, in that externalsrc may not be versioned and repeatable the way other recipes that are fixed to a specific rev are. Jun 10 17:59:16 no, there's nothing inherent about externalsrc that means you wouldn't be packaging Jun 10 18:00:01 in this instance it's that we aren't set up by default to handle non-versioned libraries Jun 10 18:00:26 I've got to go, bbl Jun 10 18:00:35 again, thank you for your help **** ENDING LOGGING AT Thu Jun 11 02:59:59 2015