On Fri, May 10, 2002 at 01:35:56PM -0700, Terry Lambert wrote:
> Mikhail Teterin wrote:
> > = For my information:  Why didn't you take John De Bowsky's advice to:
> > =
> > =       ld $objlist `lorder $liblist | tsort -q`
> > 
> > I tried that before I asked on the mailing list the first time. It
> > did reduce the number of the undefined symbols, but not to zero.
> It's possible that the symbols are truly undefined (e.g. "stat64"),
> but I think that is unlikely.
> Here is what I think:
> Your proximal problem is that your libraries are badly organized, and
> therefore certain object files in them are not being pulled into the
> linking process, because your order of operation on the objects is not
> in dependency order, because of the improper organization.

A challenge:

Linkers normally pull in everything they can from archive libraries
and do not require that object files in archive libraries be ordered
in dependency order, nor do they require archive libraries to contain
object files multiple times to break circular dependencies. They do
this by iterating over the archive library until no new binding is
possible (whether it's iterating over the index or over the whole

If you think that providing bits on the link line in dependency order
is a natural way of linking and the "proper" way of doing it, how do 
you explain our improper use of putting object files in lexical order
in libraries and how do you resolve the contradiction that from a build
point of view the lexical order is the proper way of building and we
only get away with that because the linker doesn't require object
files in archive libraries to be in dependency order (or we manually
correct the situation by duplication)?

Also, to me it looks like a gross inconsistency that can be easily
solved by having the linker remember symbols it has seen (and where)
even though they are not unresolved at the time the symbols are seen.
How does reordering or restructuring source code solely to make the
linker happy be in anyway better than simply make the linker less
dumb (be it optional)?

I don't intend to start a discussion, just contemplation when I say:

The reason linkers behave the way they do does not necessarily have
to be a good one according to current standards. I've often wondered
about what makes the current behaviour good and have never found a
reason better than "it's easier for the linker". This however can
easily be rejected as unimportant, because tools are supposed to make
it easier for the user. To me the behaviour of linkers is therefore
mostly hysterical and I personally would not use it as an argument
to distinguish good source organisation from bad...

> Most linkers don't do what you want, which is make up for programmer
> incompetence by doing an automatic topological sort on all symbol

Which programmers do you mean: the programmers writing linkers or...?


 Marcel Moolenaar         USPA: A-39004          [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to