Re: Linux, X, ld, gcc, linking, shared libraries and stuff

Randy wrote:
> Beth wrote:
> > Ah, yes...I _have_ been using Windows too long...and completely forgot
> > about the possibility of "lazy binding" in all of this because Windows
> > doesn't have that one...
>
> ???
> Are you sure? I definitely remember reading some stuff about "weak
binding"
> in the PE file format some time back. Useful for linking in floating
point
> code, but not actually including the code unless there was an actual call
to
> a specific floating point routine. This allowed you, for example, to use
a
> function like printf without linking every numeric (other other)
conversion
> routine known to man.

Let me take a look here...

"5.5.3. Auxiliary Format 3: Weak Externals

'Weak externals' are a mechanism for object files allowing flexibility at
link time. A module can contain an unresolved external symbol (sym1), but
it can also include an auxiliary record indicating that if sym1 is not
present at link time, another external symbol (sym2) is used to resolve
references instead.

If a definition of sym1 is linked, then an external reference to the symbol
is resolved normally. If a definition of sym1 is not linked, then all
references to the weak external for sym1 refer to sym2 instead. The
external symbol, sym2, must always be linked; typically it is defined in
the module containing the weak reference to sym1."

I might be interpreting this incorrectly but it says "the external symbol,
sym2, must always be linked" and refers exclusively to "link time"
throughout...

This sounds more like a kind of "aliasing" thing than "lazy binding"...

"Lazy binding", in Linux, happens at _run-time_ and is simply a case of
handling the "dynamic linking" process on a "per call" basis, when that
call is actually made...

You know, when Windows loads a DLL, it sorts out all the "dynamic linking"
there and then during load-time...with "lazy binding", this is delayed
until the symbol is _actually_ called (which potentially means that if the
code in the library is never referenced at run-time - say, a library is
only accessed when the user chooses some menu option to run a specific
function that uses that library (and no other part of the code uses it),
which the user does not actually ever choose during this execution - then
it isn't linked at all)...the advantage being that it links only that which
strictly needs it (has actually been referenced)...the disadvantage is
that, as this happens at run-time, not load or link-time, then there can be
a small "delay"...though LD uses "lazy binding" by default, you can force
it "non-lazy", if you want (which, as I was suggesting to Frank, might be a
potentially useful thing to do whilst "developing and debugging" to more
easily catch "unresolved externals" whilst actually linking, rather than
only showing up when actually running the program :)...

These are slightly different things, I think...

> > Though, surely, if it were a case of "lazy binding", though LD wouldn't
> > complain, true enough, then we should surely still be getting a
complaint
> > at run-time, when the "libc" code tries to access "errno"?
>
> Couldn't say. I looked into all this stuff many years ago, but haven't
> messed with it since. Try looking up "weak binding" or "weak external
> linkage" or something along those lines involving "weak" and see what you
> come up with.

Ah, the names sound similar but "lazy binding" and "weak externals" aren't
actually the same thing in this case..."weak externals" is a kind of
"alias" mechanism (useful, as you mention, for, say, being able to
alternatively link in some "integer only" library that "emulates"
replacements for floating-point routines in a floating-point
library...using an "aliasing" kind of mechanism)...while "lazy binding" -
at regard Linux and LD, anyway - refers to an alternative method of "late
linking"...

Actually, looking through the PE file format document, there _IS_ something
slightly similar called a "Delay-load Import Table"...this delays actually
loading a DLL until one of its functions are actually called...now, _THAT_
corresponds to the "lazy binding" that LD provides by default...

Well, okay, Windows appears that it does have it...but LD does this "lazy"
thing by default, while, with Windows...well, does anyone out there know
how you get a DLL into the "delay-load import table" instead of the usual
plain old "import table"? Windows _can_ do it - I sit corrected - but,
well, goodness knows _HOW_ you get LINK.EXE to set this up for you :)...

Anyway, before I end, I've got to get the bad joke in, haven't I?

"You are the weakest link...goodbye!"

Beth ;)


.