On Thu, 3 Jun 2021, Andrea Adami wrote:
> On Thu, Jun 3, 2021 at 4:01 PM Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> >
> > sort of a 2-part soliloquy. in current YP code base i've inherited,
> > most of the internal (local directory SRC_URI-based) recipes inherit a
> > proprietary class that, among doing other internal, proprietary
> > things, totally redefines PACKAGES as:
> >
> > PACKAGES = "${PN} ... ${PN}-dev ..."
> >
> > i had never really noticed that before, but it's pretty obvious that
> > that's not a great idea, as it allows what i call the recipe "base"
> > package (${PN}) to gather up everything that matches its standard
> > wildcard pattern before moving on, in effect "stealing" content from
> > subsequent packages they would normally get if the base package was at
> > the end, not the beginning.
> >
> > somehow, this has worked all this time, but it's clear(?) that what
> > would be the "normal" contents of the various packages isn't going to
> > be what one would expect; in particular, the base package is going to
> > be what i call "overpackaged", with lots of stuff it doesn't really
> > need so i'm guessing what's going into the image is more than is
> > really necessary. somehow, though, it's worked all this time until
> > recently, when i noticed this quirk was causing some Q/A issues, so i
> > took a deep breath, commented out that line from the class file to use
> > the default packaging approach and re-tried the build, which is when
> > all hell broke loose.
> >
> > it turns out that these internal recipes use local Makefile-based
> > source directories, which build, then install their generated
> > artifacts in a temporary (non-YP) staging area per recipe, *then*
> > manually (little by little) install stuff in ${D} via a general
> > do_install() routine, at which point the regular packaging and
> > subsequent steps kick in, but it's what now gets copied into ${D} that
> > is causing grief.
> >
> > apparently, many of these recipes generate a shared library, and i'm
> > well aware that the *normal* packaging involving a shared library is
> > like this example from libidn2 (snipped for brevity to show only
> > shared lib stuff):
> >
> > libidn2/
> > usr/
> > lib/
> > libidn2.so.0 -> libidn2.so.0.3.7
> > libidn2.so.0.3.7 [actual library file]
> >
> > libidn2-dev/
> > usr/
> > lib/
> > libidn2.so -> libidn2.so.0.3.7
> >
> > so the *normal* packaging for a shared lib is that the lib itself and
> > a symlink to it go into the base package, while another symlink goes
> > into the "-dev" package. i'd never really paid that much attention to
> > that until i reset that PACKAGES variable, as all of these internal
> > recipes end up installing into ${D} nothing but the shared lib file
> > itself under /usr/lib, and why this has worked all this time is a
> > mystery, but having made this change is generating all sorts of Q/A
> > diagnostics as this is what ends up in ${D} using a "fubar" recipe
> > example given the manual installation being done using normal
> > packaging:
> >
> > fubar/
> > usr/
> > bin/
> > ... snip ...
> > no lib/ directory
> >
> > fubar-dev/
> > usr/
> > lib/
> > libfnvcma.so [actual shared lib]
> >
> > unsurprisingly, there are QA issues with the above:
> >
> > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: -dev package contains
> > non-symlink .so: fubar-dev
> > path .../packages-split/fubar-dev/usr/lib/libfnvcma.so'[dev-elf]
> > ERROR: fubar-1.0-r0 do_package_qa: QA Issue: fubar rdepends on fubar-dev
> > [dev-deps]
> >
> > *sigh*.
> >
> > in short, because these internal recipes generate only the single
> > shared lib file itself and that's all that's copied into ${D}, the
> > regular Q/A tests will naturally barf, and i could use INSANE_SKIP all
> > over the place to get around this, but it seems to me that the proper
> > approach is to tell the developers that they need to start generating
> > the appropriate symlinks for all of their recipes so packaging is done
> > properly.
> >
> > i'm just about to check if there is a switch or class i can invoke
> > that will "fix" this issue (as in, set up the shared libs in ${D}
> > properly), but apart from that, am i correct in thinking that the
> > developers need to do this correctly from the beginning?
> >
> > rday
> >
> >
> >
>
> Hi,
> in the latter example you are packaging an unversioned shlib:
>
> libfnvcma.so [actual shared lib]
>
> In this case you might play with
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> Please have a look at
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
excellent, i was sure there was a simple solution to this.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152604):
https://lists.openembedded.org/g/openembedded-core/message/152604
Mute This Topic: https://lists.openembedded.org/mt/83283893/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
