All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: Re: python skills and bug 2412
Date: Wed, 28 Nov 2007 11:28:00 +0000	[thread overview]
Message-ID: <1196249281.8098.17.camel@localhost.localdomain> (raw)
In-Reply-To: <d543f5920711271153v5964f4e2te91f0d0347dd1e95@mail.gmail.com>

On Tue, 2007-11-27 at 13:53 -0600, Matt Hoosier wrote:
> On Nov 27, 2007 8:03 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > A proper use for RPROVIDES is for something like gtk+-directfb to
> > RPROVIDE gtk+. If an app linked against one, it should be able to run
> > against the other (I'm assuming thats the case, if its not there
> > shouldn't be an RPROVIDES).
> 
> I've tried this, and you have problems with the apps already being
> linked not only against libgtk-2.0.so.x.y.z, but also the closure of
> the dependencies which it had at link-time. So if the X11 version of
> Gtk was staged at the time your app linked, the references to
> libx11.so will exist its its binary.
> 
> Is there some way to suppress this eager resolution of transitive
> shared library dependencies?

To be honest, I don't know, its not something I've looked at before.

As Paul mentions, the shlibs code will also cause the package's
Dependencies field to become hardcoded. If the binaries have references
like you mention, that sounds like its currently doing the right thing
really...

Cheers,

Richard






      reply	other threads:[~2007-11-28 11:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-26 16:55 python skills and bug 2412 Robert Schuster
2007-11-27 12:22 ` Richard Purdie
2007-11-27 13:43   ` Paul Sokolovsky
2007-11-27 14:03     ` Richard Purdie
2007-11-27 14:17       ` Paul Sokolovsky
2007-11-27 15:05         ` Richard Purdie
2007-11-27 15:19           ` Build-time vs run-time virtuals, was: " Paul Sokolovsky
2007-11-28 11:30             ` Richard Purdie
2007-11-27 19:53       ` Matt Hoosier
2007-11-28 11:28         ` Richard Purdie [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1196249281.8098.17.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.