All of
 help / color / mirror / Atom feed
From: "Andrea Adami" <>
To: "Robert P. J. Day" <>
Cc: OE Core mailing list <>
Subject: Re: [OE-core] want to clarify proper approach to shared lib (.so) installation
Date: Thu, 3 Jun 2021 16:15:14 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jun 3, 2021 at 4:01 PM Robert P. J. Day <> 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/
> ->
>                    [actual library file]
>  libidn2-dev/
>   usr/
>    lib/
> ->
> 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/
>            [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/'[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

in the latter example you are packaging an unversioned shlib:            [actual shared lib]

In this case you might play with
 SOLIBS = ".so"

Please have a look at


  reply	other threads:[~2021-06-03 14:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 14:00 want to clarify proper approach to shared lib (.so) installation Robert P. J. Day
2021-06-03 14:15 ` Andrea Adami [this message]
2021-06-03 14:26   ` [OE-core] " Robert P. J. Day
2021-06-04  7:58     ` Andre McCurdy
2021-06-04 11:46       ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.