This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lazy load shared objects using gcc

On 10-Aug-2002, Roberta Reidel <> 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 ' 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 <>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]