Date: Sun, 12 May 2002 15:00:07 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Mikhail Teterin <mi+mx@aldan.algebra.com>, current@FreeBSD.ORG Subject: Re: does the order of .a files matter? Message-ID: <20020512220007.GA21019@dhcp01.pn.xcllnt.net> In-Reply-To: <3CDC2F2C.2CB9C818@mindspring.com> References: <200205101233.g4ACXctb041093@corbulon.video-collage.com> <3CDBFA7E.A2A1F09F@mindspring.com> <200205101343.01636.mi%2Bmx@aldan.algebra.com> <3CDC2F2C.2CB9C818@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 archive). 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 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020512220007.GA21019>