**** BEGIN LOGGING AT Thu May 31 03:00:07 2018
May 31 16:50:42 <tlwoerner> i'm looking for some clarity on .so file naming/numbering
May 31 16:51:46 <tlwoerner> i have a recipe for a library, it creates a PACKAGE called ${PN} that contains the ${libdir}/libtss2-tcti-device.so.* and a ${PN}-dev that contains the ${libdir}/libtss2-tcti-device.so
May 31 16:52:27 <tlwoerner> then there's an app that dlopen()'s that library, but when it does, it dlopen()'s libtss2-tcti-device.so, not libtss2-tcti-device.so.0
May 31 16:54:02 <tlwoerner> so i want to ping the developers and tell them they're doing it wrong, but i want the facts in order to be more convincing; otherwise i'll have to package up the libtss2-tcti-device.so in the ${PN} package
May 31 17:06:06 <kergoth> the app doing the dlopen is doing it wrong, it needs to open the SONAME, not the development-only symlink
May 31 17:06:17 <kergoth> dlopening a .so for a plugin makes sense, a library not so much
May 31 17:27:53 <khem> yeah dlopen is so abused with respect to soname gsteamer plugins reminds me
May 31 17:32:37 <tlwoerner> i'll submit a patch and hope they see the sense of it; any chance someone can find a link to something "authoritative"?
May 31 17:32:53 <tlwoerner> the example in the dlopen() man page uses a full name, maybe that'll help
May 31 17:33:42 <tlwoerner> otherwise i'll just point out that the first major number should be included, otherwise chaos will ensue when the API changes (and hope they agree)
May 31 17:41:25 <kergoth> well, you don't need the .so link to run binaries linked against it normally, why would you need it to run binaries that dlopen it?
May 31 17:41:32 <kergoth> but yeah, i'm not sure if there's a definitive reference about it
May 31 18:15:47 <khem> soname symbol versioning is not mandated by ELF or other standards so in a way not using versioning is with in limits
May 31 18:15:51 <khem> though its lousy
May 31 18:28:44 <tlwoerner> am i crazy, or does "devtool deploy-target <recipe> <target>" install all PACKAGES associated with a recipe?
May 31 18:30:05 <tlwoerner> 'cause all of a sudden, i have the .a the .so and the man files
May 31 18:34:57 <khem> I think it deploys all
May 31 18:35:29 <tlwoerner> yea, it looks that way, undeploy-target removes the extra stuff
May 31 18:36:04 <tlwoerner> from the help text, it looks like deploy-target takes its files from the "image" directory in the build
May 31 18:36:27 <tlwoerner> haven't seen paul around in a while, holidays?
May 31 19:11:46 <tlwoerner> yep, that's what it's doing: http://git.openembedded.org/openembedded-core/tree/scripts/lib/devtool/deploy.py#n172
May 31 19:12:52 <tlwoerner> is there a fancy OE variable for ${WORKDIR}/packages-split ?
May 31 19:15:04 <khem> may be PKGDEST ?
May 31 19:17:23 <tlwoerner> khem: yes, thanks!
May 31 20:12:49 <tlwoerner> that was easier than i thought it would be: https://patchwork.openembedded.org/patch/151286/
May 31 20:13:04 * tlwoerner waits to see what the gurus will think
Jun 01 01:49:50 <khem> so archlinux switched to pkgconf 
Jun 01 01:49:57 <khem> :: Starting full system upgrade...
Jun 01 01:49:58 <khem> :: Replace pkg-config with core/pkgconf? [Y/n]
Jun 01 01:58:13 <kergoth> khem: huh,nice
Jun 01 02:12:12 <khem> yeah arch is pretty aggressive in moving to new things and they time it well 
Jun 01 02:18:35 <kergoth> finally fixed/updated my arch install/setup scripts, so i'm running it in a VM for builds and also using arch on WSL now
Jun 01 02:18:41 <kergoth> i'd missed pacman
**** ENDING LOGGING AT Fri Jun 01 03:00:09 2018