**** BEGIN LOGGING AT Thu Jun 25 02:59:59 2015 Jun 25 16:47:56 how does bitbake determine implicit dependencies (e.g. building openssl requires glibc without explicitly stating so)? Jun 25 16:48:56 in the case of glibc, that's added magically Jun 25 16:49:11 base.bbclass adds gcc, compilerlibs and libc to depends unless you set INHIBIT_DEFAULT_DEPS Jun 25 16:50:58 rburton: what about other libraries? such as when packages depend on openssl? Jun 25 16:51:15 what do you mean? Jun 25 16:51:34 there is a piece that look sfor libraries for packages Jun 25 16:51:36 it simply doesnt; QA will check runtime deps Jun 25 16:51:47 but it wont know it needs it before building it Jun 25 16:51:49 if i make a change to openssl and rebuild an image, a lot of packages rebuild, but there's no explicit dependency on openssl declared Jun 25 16:51:53 and if it cant build, you're screwed Jun 25 16:52:28 bencoh: you mean the package_qa task? Jun 25 16:52:49 I guess that's the name Jun 25 16:53:17 but that's for runtime/rdepends, not build-time/depends afaik Jun 25 16:53:36 are implicit dependencies considered rdepends? Jun 25 16:54:04 ? Jun 25 16:54:11 consmith: changing openssl will only cause a rebuild of recipes depending on openssl Jun 25 16:54:32 the only "implicit" dependencies in the system are the automatically determined runtime dependencies which end up in the binary package metadata, but don't affect how bitbake builds anything Jun 25 16:54:57 kergoth: when I change openssl and rebuild an image over 100 packages rebuild, none of which have DEPENDS or RDEPENDS with openssl in them Jun 25 16:55:09 do you not understand the concept of recursion? Jun 25 16:55:11 consmith: bitbake -g Jun 25 16:55:20 and read the .dot files Jun 25 16:55:29 openssl changes, everything depending on openssl changes, and then everything depending on those recipes rebuild, etc, rippling out through the dependency graph Jun 25 16:55:41 s/on openssl changes/on openssl rebuilds/ Jun 25 16:55:59 kergoth: but I'm saying I can't find *anything* that explicitly depends on openssl Jun 25 16:56:07 then learn to grep Jun 25 16:56:13 or examine the .dot file as bencoh suggests Jun 25 16:56:19 or use bitbake -g -u depexp Jun 25 16:56:31 plenty of recipes explicitly depend on openssl Jun 25 16:56:58 I'd love a curse depexp :) Jun 25 16:57:03 i tried grep but couldn't get results Jun 25 16:57:12 bencoh: i'll try that, thanks Jun 25 16:58:07 there's more than just explicit *unconditional* DEPENDS additions involved Jun 25 16:58:17 lots of recipes have dependencies depending on their PACKAGECONFIG configuration Jun 25 19:39:04 Is there a good reason to make a shared library a build-time dependency instead of a run-time dependency? Specifically, I can only find one package that lists openssl in RDEPENDS. All the other packages that depend on openssl list it in DEPENDS. Jun 25 19:41:58 did you mean is there a good reason to make it a runtime dependency? Jun 25 19:42:02 because thats almost never needed Jun 25 19:42:10 buid time is the common case, because you can't link against a library without it Jun 25 19:42:32 the only reason you'd need a runtime dependency on it would be if it didn't link against the library. e.g. if it's a script that runs the 'openssl' command Jun 25 19:42:52 at packaging time, we automatically add runtime dependencies for any shared libraries that were linked at build time Jun 25 19:47:09 hmm, it's been a while since I've dealt with linking so forgive my ignorance, but are you saying that a .so is needed at build-time by applications that use it? Jun 25 19:56:38 thats what a build dependecy is, yes, it needs it to build/compile Jun 25 19:58:18 i thought the point of a shared library was to allow for dynamic linking(?) Jun 25 19:59:41 google is your friend. alternatively, read the book "Linkers and Loaders" Jun 25 20:02:28 I've been searching. So are you saying that shared libraries are *not* dynamically linked? Jun 25 20:16:20 again, i'm not here to teach a class on how dynamic linking works Jun 25 20:18:45 consmith: some apps may use .so's via dlopen in run time. Jun 25 20:50:14 mario-goulart: if an app uses dynamic loading like that, would the recipe still specify a build-time dependency? As I understand it, dynamic loading allows for plugin support, in which case the library may not be available at build time. I'm guessing (based off the comments above) that most apps are not using dynamic loading, and instead do need the library to be present at build time in order to record its path name. Is that correct? Jun 25 20:56:37 consmith: it pretty much depends on build systems. Theoretically, build systems should not require plugins to be available at build time. But who knows... :-) Jun 25 21:00:59 mario-goulart: okay, thanks for the help Jun 25 21:02:34 yw Jun 25 21:06:15 consmith: when dlopen is used, no, build time is not generally necessary, though it may still be for e.g. m4 macros for autoconf. but that's *not* the common case, the vast majority of the time they need a build dependency to link against a library, shared or static Jun 25 21:07:31 i see that now, thanks **** ENDING LOGGING AT Fri Jun 26 02:59:58 2015