Mikhail Teterin wrote:
> = I explain the lexical ordering by way of the following commands when
> = exiting the Makefile in "vi" in command mode:
> =
> = !!ls *.c
> = ISRCS=<esc>
> =
> = 8-).
> This does not explain anything. Whatever the joke was, I did not get it.

These are the commands you give the editor to take the output of
"ls *.c", and put all the files on a single line:

        SRCS=aardvark.c bear.c cat.c dog.c elephant.c ...

In other words, the lexical ordering comes from the fact that the
output of the "ls" command is sorted alphabetically.

> The question stands -- why can the object files be given to the linker
> in arbitrary order,

Because .o files are object files which it is mandatory to include in
the final executable.

> but the the static libraries must be carefully ordered -- possibly
> even listed multiple times!

Because .a files are archives containing lists of object files which
it is *optional* to include in the final executable.

> There is nothing
> apparent in the .a format, that forces such behaviour.

Uh... .a files are archives containing lists of object files which
it is *optional* to include in the final executable.

> 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...

Because programmers are intrinsically lazy, and write Makefile's

Also, the speedup is really questionable.  The dependency graph is
going to be created as if the symbol satisfaction order were random
anyway.  And, in fact, unless you put one function per object file,
you really can't guarantee that tsort will minimize the sorting
necessary.  You are assuming -- perhaps incorectly -- that the
functions were broken up between source files in tsort order.

> = 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.

We apparently differ on our definitions of "right in front of its nose".

Also... it's not "our linker", it is "FSF's linker".

See also the "info ld"; if you wanted an implicit "--start-group"
at the start of all object lists, and an implicit "--end-group" at
the end, then you could hack it to support it.  But, I would not
want it in my local FreeBSD; from the documentation:

     Using this option has a significant performance cost.  It is best
     to use it only when there are unavoidable circular references
     between two or more archives.

> = 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.

Or invent new ones, leaving the old ones intact.

-- Terry

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

Reply via email to