All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Haitzler (The Rasterman) <raster@rasterman.com>
To: openembedded-devel@lists.openembedded.org
Cc: openembedded-devel@openembedded.org
Subject: Re: [oe-commits] Koen Kooi : initscripts: only run ldconfig on boot when ld.so. conf is present
Date: Sun, 2 Nov 2008 10:08:19 +1100	[thread overview]
Message-ID: <20081102100819.ebdb2ce9.raster@rasterman.com> (raw)
In-Reply-To: <1225539496.4090.6.camel@utx.utx.cz>

On Sat, 01 Nov 2008 12:38:16 +0100 Stanislav Brabec <utx@penguin.cz> babbled:

> Koen Kooi wrote:
> 
> > I don't have a strong opinion on that :) People more knowledgable about 
> > ldconfig should chip in on this topic.
> 
> And what about something like:
> if ..../ld.so.cache -ot /usr/lib -o /etc/ld.so.cache -ot /lib ; then
>     /sbin/ldconfig
> fi

you'd need to include all dirs in ld.so.conf in addition... also doesn't cover
me overwriting existing .so's in the lib dir with new ones. :)

really - if you install a lib from source or some tarball - run ldconfig. it's
been this way since the dawn of time. if you don't know this then the only sure
way to "fix" this to work is to reboot which is incredibly stupid. :) imho
running it on boot at all is just a silly idea full-stop. it should be run
immediately post-install/upgrade etc. of any shared lib(s) and they will
immediately be usable. a reboot is a horrible way to trigger that. :)

> Call ldconfig only if ld.so cache is outdated. Fast for users of package
> managers, working for others, fast in subsequent reboots.
> 
> I guess that all package managers use method "fill new file in target
> directory, then replace existing", so timestamp of library directory is
> updated on any change.

yes. as do most source installs using "install" (unlink old file, write new).
BUT if you are using a package manager.. it runs ldconfig for you.. and not on
boot - after install! if it doesn't - it is a fundamentally broken package
manager. source installs do not. as do simple untars of binaries. but if you
are doing this i'd expect you to have enough clue to run ldconfig - and not
just "reboot" to fix it :)

basically - i am trying to dig for a "sane justification" for putting ldconfig
in on boot. the only one i can think of is:

at some point when oe was building images, it was unable to run ldconfig using
qemu natively within the rootfs before converting to a file system image (ext2,
jffs2, or tar etc.) and thus as a workaround to not being able to do this, it
was run on boot to populate ld.so.cache. it's possible to do this now via qemu
before packaging up the rootfs.

ooh wait. i found out...

/var/run/ld.so.cache... it's in /var/run ... which is /var/volatile - which is
ramfs. which means it's not persistent. this... is a problem. well a problem
for systems that can do persistent storage and modify the fs runtime (and keep
the changes - ie anything using jffs2).

perhaps.. this is what needs changing - distros that have non-writable rootfs's
use ldconfig on boot (makes sense now) and those with, do it at image creating
time with qemu (and henceforth let the package manager handle it).

> Note that /etc/ld.so.conf contain also /usr/local/lib (not exists by
> default, but defined by FHS) and /usr/X11R6/lib (obsolete).
> 
> 
> ________________________________________________________________________
> Stanislav Brabec
> http://www.penguin.cz/~utx/zaurus
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com




  parent reply	other threads:[~2008-11-01 23:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081031110045.7EF89189333@amethyst.openembedded.net>
2008-10-31 12:37 ` [oe-commits] Koen Kooi : initscripts: only run ldconfig on boot when ld.so. conf is present Carsten Haitzler
2008-10-31 15:55   ` Koen Kooi
2008-10-31 21:53     ` Carsten Haitzler
2008-11-01  8:22       ` Koen Kooi
2008-11-01 11:38         ` Stanislav Brabec
2008-11-01 19:20           ` Phil Blundell
2008-11-02  7:45             ` Koen Kooi
2008-11-01 23:08           ` Carsten Haitzler [this message]
2008-11-02  4:51             ` Denys Dmytriyenko
2008-11-02  6:37               ` Carsten Haitzler
2008-11-02 10:52             ` Stanislav Brabec
2008-11-02 11:25               ` Running one-off target binaries, was: " Koen Kooi

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=20081102100819.ebdb2ce9.raster@rasterman.com \
    --to=raster@rasterman.com \
    --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.