From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-01-04 02:44:18
Dan W. wrote:
> Rene Rivera wrote:
>>> To be honest I'm not 100% sure either, but close to it... that a
>>> typical linker will remove fat from your .obj, but not from a .lib;
>>> --but I could be wrong.
>> The typical linker will only include the code, including dependent
>> code, only for externally visible symbols, regardless of its origin. And
> Ha! I didn't think they were that smart.
Don't worry they are brain damaged in other ways ;-)
>> depending on the type of loader support the loader can do the
>> equivalent at load time (load only what is needed/used).
> You mean dynamic libraries?
Yes. Although just about everything is a dynamic object on most OSes.
>I whould have thought the whole file would
> be put in memory... Would you not risk going through disk latency
> multiple times, loading a .dll/.so piece-meal?
On most OSes (specialty ones, like embedded, excepted) the virtual memory
system is used to map the files onto memory so most of the latency is there
regardless. Doing the extra work at function call time is worth the penalty if
the use coverage is not large.
>> *But* most developers use the linker in an "export everything" mode.
> Most programmers default the compiler optimizations to speed; I always
> default them to size. I suppose this choice prevents the "export all"
> syndrom you speak of?
No. It has almost nothing to do with the *compiler*. The only way the compiler
is involved is in telling the linker which symbols are externally visible. And
getting your compiler of choice to let you tell it what those symbols are is
difficult, for the most part. For example, just look at how hard it's been to
get the DLLs/SOs for the Boost libraries working. And even here for
non-Windows platforms the best we can do is to tell the compiler+linker to
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk