Hi Trevor,
On Friday, 1 June 2018 2:23:59 PM NZST Trevor Woerner wrote:
> Earlier today I was working on recipes for some software which recently
> added the feature to dlopen() one of a couple shared objects based on
> various conditions. But instead of dlopen()'ing the SONAME, they were
> dlopen()'ing the raw .so file. OE's default packaging, of course, added the
> *.so.0 and *.so.0.0.0 files to the ${PN} package, and the raw *.so files to
> the ${PN}-dev package. So when the app tried to run, it failed.
>
> Investigating, I realised there were two things I could do: 1) add the raw
> *.so files to the ${PN} package (with INSANE_SKIP += "dev-so") or 2) fix
> the app. I decided to try #2, with the help of devtool.
>
> I made one small change to the app, "devtool deploy-target"'ed it, and,
> AMAZINGLY, everything worked!! Wow, what luck! ... or not.
>
> Investigating, I discovered that "devtool deploy-target"'s only mode of
> operation is to upload the entire recipe's ${D} directory (i.e.
> ${WORKDIR}/image) to the target! I hope you'll be as surprised by that as
> am I. Considering ${D} includes *.a files, man pages, raw *.so files,
> pkgconfigs, (... thankfully it doesn't also include the -dbg packages) that
> is a lot of stuff to be uploading to the target, a lot of wrong stuff, and
> in my case that hindered my work. Most target filesystems are only 10%
> larger than required to hold their contents, so uploading static libraries,
> man pages, pkgconfigs, etc is not great.
This is intentional. The reason we do it this way is it frees the user from
having to resolve any packaging issues that might otherwise prevent them from
actually getting early development code onto the device to test - package QA,
but also what if important files simply aren't in the right package? The user
will then have to go and figure out how to fix that before they can get any
further. devtool is supposed to shorten people's development cycles,
especially if it's early in development and they tend to be a bit less patient
to see something working on target.
Now, I appreciate that the flipside of the same coin is that there are issues
we might pick up as part of package QA that would be helpful to highlight to
the user (e.g. binary architecture was wrong), so it may be that we should
revisit this, but I wouldn't want to wholesale switch over to packaging output
by default - we'd need to be a bit more careful about it.
I will note that a small issue with your patch is that if you do use --package
you can no longer just use devtool build to build what you need to deploy,
since that only builds up to do_populate_sysroot / do_packagedata. This in
turn means that you can't use this option within the eSDK as you can't
conveniently run bitbake there (again, intentional).
I'm not violently opposed to this patch, but everyone does need to understand
what the caveats are so we may need some extra notes in the help text at a
minimum.
> I checked at the time, but I'm not 100% sure now, but I believe if one
> deploys two packages from one recipe, the on-target file gets appended. But
> now I'm not 100% sure, so I'll verify this tomorrow (thanks for the
> reminder).
The way I recall writing it, it will remove whatever it deployed last time, so
I would be surprised if it were incremental.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
