This is the mail archive of the
mailing list for the GCC project.
Re: lazy load shared objects using gcc
- From: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- To: Roberta Reidel <P dot R dot Reidel at t-online dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 12 Aug 2002 15:40:50 +1000
- Subject: Re: lazy load shared objects using gcc
- References: <17dRm6-1oAqxsC@fwd06.sul.t-online.com>
On 10-Aug-2002, Roberta Reidel <P.R.Reidel@t-online.de> wrote:
> i always assumed 'lazy load' to be the default configuration of the
> g++/gcc 'frontend'. But i tested this using gcc version 2.96 on
> RedHat 7.1/7.2, and it seems to be 'load now' the default configuration.
> Reading the man/info pages of gcc and ld, i guess the ld to support 'lazy
> load' ( the -R <file> option ). But the gcc doesn't know any option, except
> ' -z now ' --- to *turn off* lazy loading. This confirms my assumption of
> 'lazy load' beeing the default.
> But it doesn't: The error message of missing shared libraries always appears
> on start time.
I suspect that the default behaviour is mostly-but-not-fully-lazy.
That is, it reads in the .so file and does a little bit of set up work,
but does not resolve most of the symbols.
> To decide between two hardware subsets (eg. pcmcia cards)
> i simply want to decide to engage the card of type one or two.
> a simple ' gcc MainApplication.cpp CardTypeOne.so CardTypeTwo.so ' should
> call the compiler, Assembler and linker -- preparing lazy load. But it does
> a 'load now'. (And this doubles the time to start the Application.)
Have you measured the overhead?
On modern hardware the time to link in a single .so file is very small,
and is unlikely to be worth optimizing.
Fergus Henderson <email@example.com> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.