Date: Mon, 13 May 2002 10:52:36 -0400 From: Mikhail Teterin <mi+mx@aldan.algebra.com> To: Terry Lambert <tlambert2@mindspring.com>, Marcel Moolenaar <marcel@xcllnt.net> Cc: current@FreeBSD.ORG Subject: Re: does the order of .a files matter? Message-ID: <200205131052.36927.mi%2Bmx@aldan.algebra.com> In-Reply-To: <3CDF57EF.443F3BE7@mindspring.com> References: <200205101233.g4ACXctb041093@corbulon.video-collage.com> <20020512220007.GA21019@dhcp01.pn.xcllnt.net> <3CDF57EF.443F3BE7@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 13 May 2002 02:06 am, Terry Lambert wrote: = > 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)? = I explain the lexical ordering by way of the following commands when = exiting the Makefile in "vi" in command mode: = = !!ls *.c = JJJJJJJJJJJJJJJJJ[...] = ISRCS=<esc> = = 8-). This does not explain anything. Whatever the joke was, I did not get it. The question stands -- why can the object files be given to the linker in arbitrary order, but the the static libraries must be carefully ordered -- possibly even listed multiple times! There is nothing apparent in the .a format, that forces such behaviour. All of our Makefiles list objects in the alphabetical order -- why not sort them once with lorder/tsort and skip the lorder/tsort step from the library build (in bsd.lib.mk)? That would also speed up world-building... = Linking fewer object files into an executable makes the executable = smaller. Smaller executables are better than larger executables from a = putatively "smarter" linker (personally, I measure linker intelligence = as inversely proportional to the resulting executable size, relative = to the idealized executable size). Terry, NONE of this is relevant to the subject. Nobody is criticizing our linker for not putting UNNEEDED objects into the executables. The gaping hole in the linker, that is the subject of this thread, is the linker's inability to find NEEDED objects, which are right in front of its nose. = I had a big gripe, complete with examples involving famous names, = ready to go. But I will replace it with a much smaller response: = = "A craftsman must know his tools". And always seek to improve them. -mi 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?200205131052.36927.mi%2Bmx>