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

Wannabee wrote:
> Beth wrote:
> > Wannabee wrote:
> >> Beth wrote:
> >> > "You are the weakest link...goodbye!"
> >>
> >> Oki :) anyway, maybe I misunderstood you. Read to fast.
> >
> > Don't worry; It's a confusing issue...everyone, so far, seems to be
> > saying
> > "don't ask me" or mixing up the names or getting confused about it
> > somehow...and, you know, we're the ASM coders who usually know this
stuff
> > better than most...so goodness knows what the C programmers are
thinking
> > about it all! ;)...
>
> In my Win32.hlp file, the closest I can come to finding Lazy binding, is
> nothing,

Yeah, exactly...that's why I thought it wasn't possible at all...but,
apparently, there is "support" for something like it in the PE file
format...no-one ever seems to bother with it for anything...Microsoft don't
bother telling anyone it's there...but, well, it is there...

> and Late binding seems to be some OLE stuff. And that I do not
> know anything about.

Ah, that kind of "late binding" is something completely different to do
with OOP...

> But dynamic linking, which is listed in you list of "synonyms" usually
> means exactly the code I posted.

Oh, watch out...that list was "sound-alikes", NOT "synonyms"...they don't
all mean the same thing...my point there was there were too many names that
are too easily confused with one another, not that they were all "synonyms"
of each other (though, some were...but not all of them)...

Actually, "dynamic linking" covers more than one thing...as, really, it
just means "not static linking", so to speak...really, it's "lazy dynamic
linking" or "run-time dynamic linking" or whatever...you know, they are all
"dynamic linking" because that just refers to perform the "link" while
loading / running the program (or, if you like, not doing it all at
"link-time", which would be "static linking")...but they are different
"types"...different ways to achieve the "linking"...

> Anyway, if some pe linking stuff is late binded or not, this will not
> prevent from errors, when the link is actually done, so if what we are
> talking about here is linking to a DLL, or any other file outside the PE,
> it would be best, when crashes and abortions would be avoided to use
> Dynamic linking, as in this case you could check for the presents of the
> file you need, in some cases, and simply cut that functionality away.

Yes; "lazy linking" has nothing to do with "preventing errors"...at best,
it's a small "optimisation" and not even one that's always useful for every
program...

LD's attitude to this, I think, is to make it a "default", simply because
the "worst case scenario" - all libraries are immediately needed straight
away - ends up being more or less equivalent to how "non-lazy" linking is,
anyway, at all times (dealing with it all at the beginning, in the loading
phase)...hence, it's a "why not?" situation...it _might_ benefit some
programs here and there in small ways but it shouldn't in any way "harm"
any typical program...and, regardless, it is a "default" only: If you
really don't want or need this for whatever reason, then add the "switch"
which makes the dynamic linker behave "non-lazy"...

Also, yes, I fully agree with you that, ideally, every program should "do
it manually", in order to be more robust, provide better error recovery and
so forth...

I already stated (somewhere in the thread ;) that, eventually, it might
make sense to make LuxAsm uses "manual" dynamic linking throughout (for the
"modules", these _must_ be handled that way because of the "plug-in" way
they work...and, well, once we've written such code for that, it can be
made "generic" to deal with any and all libraries...so, as noted, we _must_
write such code at least for the purposes of the "modules"...hence, it
would actually be a _WASTE_ not to re-use the code to also deal more
generically with _all_ libraries through it and be able to provide better
error reporting and avoid crashes and, well, produce a much more "robust"
kind of product...plus, being "Linux specific" without need for
"portability", then many of the "libraries" aren't actually needed, in
fact...the kernel, via "INT 80h" / "SYSENTER" requires no "library" to
access..."libc" we don't need...C, the person, is already investigating and
developing code for an "ASM Xlib" replacement that we probably won't need
that library (or have to suffer "libc" for its sake)...and so on, that,
eventually, we won't necessarily be needing much of any "libraries",
anyway...it is quite possible, in fact, that we could even reach the point
that all LuxAsm code requires NO "libraries" present _at all_ to
function...and the only use of "dynamic linking" is for our own "modules"
to be able to "plug-in" to each other (which is delibrately designed to be
"scalable": If it can find one of its "companion" LuxAsm "modules" then it
"integrates" with it but, if it can't, then it "falls back" to simple
"stand-alone" behaviour...all such "integrated" features provide _more_
than you "traditionally" get, so if they can't or don't "link" to each
other, then it'll only "fall back" to behaving like an ordinary
"traditional" assembler toolset :)...

Just to avoid confusion and conflict:

1. "lazy binding" is only being mentioned because it's LD's
"default"...hence, all the code examples we've been doing so far have been
"lazy bound"...this effects when we can expect to see the "error message"
appears (you know: "static linking", the errors appear while linking,
"non-lazy dynamic linking", they appear when you start the program, "lazy
binding" and they appear when the program makes "first access" to that
library :)...so, simply, "lazy binding" was just something we should
"remember" while testing our code snippets...because it effects _when_ we
might see any "error messages"...it's not that we really in any way
"desire" having "lazy linking": Indeed, LuxAsm follows its own "linking"
method between "modules", anyway...

2. Windows does also allow for a "delay-load import table" to be in the PE
file...so, yes, Windows can actually do exactly similar, if that table is
used...I was merely in error to think Windows couldn't do it because, well,
as you yourself have been saying, Microsoft don't seem to mention this
option in their documentation anywhere, no-one seems to be using this
option in any programs I've ever seen (where, obviously, I was actually
bothering to check how they worked...I _might_ have seen such a program
unknowingly so without realising :), I never saw any mention of this in the
(sparse) LINK documentation on the web, etc., etc....you know, I took this
to mean that it wasn't possible...but it is possible and is just something
that apparently no-one actually ever uses or Microsoft don't really seem to
want to tell anyone about...

So, you know, this thread isn't about "how wonderful lazy binding
is!!"...on the contrary, it's a potential PITA regards "testing" our
code...we only started mentioned it because T.M. rightly reminded us that
it _could_ effect when and what "error messages" we see while
"testing"...indeed, because of this, I even suggested to Frank that, for
development and testing, forcing "non-lazy binding" might make sense...you
know: If there are errors then we _want_ to know about them, so "force"
non-lazy binding for any and all "file not found" errors to appear
immediately at program start...this is much more useful for developing...it
can be switched back to "lazy" for public release, if needed (though, there
_might_ not be any great reason to do so...you know, "lazy binding" isn't
magic and, sometimes, there's no a great deal of point switching it
on...but - which is why LD has "lazy" as its "default" - it can't get any
"worse", really, than what "non-lazy" does anyway...well, except for the
additional bits of "overhead" needed to implement it :)...

It was only a "passing comment" that I believed Windows didn't support
it...but, on closer inspection of the PE format, it _does_ support
it...this was not any intentional thing...probably like me, you've also
never seen this possibility mentioned in any Microsoft documentation or as
a "linker option" to their linkers or whatever...as such, because I'd seen
absolutely no instances of this actually been used or mentioned or
documented anywhere (except as a small obscure "section" in the PE format
specification, which I missed noticing until Randy's "are you sure?"
comment made me take another look there :)...well, it was wrong, true, but
not really unreasonable that I just "presumed" this was probably because it
wasn't possible to do it at all...rather, though, it is possible and it's
just the case that "no-one bothers" instead...

So, you know, there really isn't anything to "fight" over here...I did make
a mistaken assertion about Windows but, you know, Randy already picked me
up on it with the "are you sure?" point (okay, Randy got the wrong name -
but he did admit to having "not looked it up for ages", so, "well done"
that he remembers it at all! - but his actual point was perfectly correct,
once we substitute the correct name in there :)...to which I conceded that
I did perfectly "jump the gun" on that one - I can see in the PE document
that there is such a thing (despite the wrong name, I thought - just to be
sure - that I'd scan through all the other entries to really make sure it
wasn't in there and stumbled into "delay-load import tables", which do
appear to be "lazy binding" ;) - so, you know, I've already retracted that
assertion...

What can I say? Microsoft mislead me into thinking it wasn't there by never
bothering to mention it anywhere but as a small obscure "section" in their
PE document...ironically, from Rene's perspective anyway, is that it was
Randy who actually guided me away from being "mislead" by Microsoft
themselves to the correct answer ;)...

Nevertheless, this is all really a bit on the "trivial" side...we don't
even want "lazy binding"...it's just a case that we've been given it by
"default" from LD, so, you know: We have to learn how that works and
account for it happening, to make proper sense of what "error messages" we
are and aren't seeing...it is, in fact, in this context, being a bit of a
"pain in the arse", to tell the truth...not that the feature is "wrong" or
"evil" - it can be potentially useful - but not for us and not now, it
isn't ;)...

Beth :)


.

Relevant Pages

  • Re: CollectionChanged event
    ... Never mind!! ... The documentation seems to be wrong, ... > want to be able to detect if the binding is removed. ... > event fires, and thus I must somehow compare the collections? ...
    (microsoft.public.dotnet.languages.vb.controls)
  • Re: Curses binding?
    ... Ada, for example on Linux. ... A Google search turned up the *documentation* ... for such a binding, but the actual code itself eludes me. ...
    (comp.lang.ada)
  • Re: Curses binding?
    ... A Google search turned up the *documentation* ... for such a binding, but the actual code itself eludes me. ... AFAIK ncurses comes with Ada bindings. ...
    (comp.lang.ada)
  • Re: commenting, was Re: Use of declare blocks
    ... Minimal documentation ... For example, in developing a binding to some API, I do a lot of throw-away ... makes it easy to refresh my memory, ...
    (comp.lang.ada)