public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-portage-dev@robin.gentoo.org
Subject: Re: [gentoo-portage-dev] RFC: Binary dependency tracking
Date: Wed, 6 Apr 2005 12:12:52 +0200	[thread overview]
Message-ID: <200504061213.00335.pauldv@gentoo.org> (raw)
In-Reply-To: <1112740704.31455.20.camel@cid.outersquare.org>

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Wednesday 06 April 2005 00:38, Jeremy Huddleston wrote:
> Well, I've glossed over the dlopen() issues for now as I'm not sure the
> best way to handle that or even if it needs to be addressed.  How often
> does something dlopen() a file if it doesn't know the exact filename at
> compile time?  It seems unlikely to me that this kind of dependency
> would be introduced which wouldn't be uniquely satisfied by the
> RDEPEND. Does anyone know of a case where we'd do something like:

In general dlopen is used for plugins. Dlopen allows to define library 
requirements at runtime. Often these requirements are optional in the 
case of plugins and the like. With plugins the name of the plugin is 
often unknown. For required dependencies where the name is allready known 
in advance it doesn't really make sense to use dlopen which is a lot more 
complex than a normal link.

If you look at kde it massively uses plugins. One of the tricks that is 
played is caused by the fact that the kde and qt libraries are massive 
(take quite a time to load) and shared by most kde applications. The 
trick is then to run a process (kdeinit) that is allready loaded and have 
this process fork and let the fork load the actual application as plugin. 
This result in faster load times even (especially) in absense of 
prelinking.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      parent reply	other threads:[~2005-04-06 10:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1110961726.2948.72.camel@cid.outersquare.org>
     [not found] ` <20050316181919.GC31829@freedom.wit.com>
     [not found]   ` <200503162102.25494.pauldv@gentoo.org>
2005-04-05 22:38     ` [gentoo-portage-dev] RFC: Binary dependency tracking Jeremy Huddleston
2005-04-06  7:23       ` Brian Harring
2005-04-06 10:12       ` Paul de Vrieze [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=200504061213.00335.pauldv@gentoo.org \
    --to=pauldv@gentoo.org \
    --cc=gentoo-portage-dev@gentoo.org \
    --cc=gentoo-portage-dev@robin.gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox