Re: does the order of .a files matter?
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 = J[...] = 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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
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 = J[...] = 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 last? 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
Re: does the order of .a files matter?
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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Marcel Moolenaar wrote: 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 Actually, they don't. They only pull in onjects that define symbols that are undefined at the time the library is encountered, in order, on the linker line. Anyone who doesn't believe this needs to write an X11 application that uses Xt, Xext, and some widget toolkit, and then play with library order other than -lX11 -lXt -lXext. 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). Actually, they do this by looking at the library symbol index, which is either created automatically by the ar, or, on BSD based systems, added by the program ranlib. 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 J[...] ISRCS=esc 8-). 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. info ld This is not historical UNIX ld behaviour, and it is not default GNU ld behaviour. 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)? When you are using a library as a library, rather than as a silly workaround to command line length limitations, you only want to pull in the object files from the archive which are actually used. By ordering the source code properly, less code gets pulled in when you are not actually using every function within a library. 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). Also, putting related code adjacently results in the code fitting within the peephole. This permits the cimplier's optimizer to do things that it would otherwise be unable to do. Optimized executables are better than those that aren't. So organizing functions into the correct object modules, and the object modules into correct libraries, rather than choosing the organization at random, is important, if you care about code size and/or optimizer efficiency. 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... The most common excuse I'm aware of is To get faster compile times when benchmarked against other compilers. On slow enough, or emulated, hardware, though, it's a legitimate complaint that linking speed becomes a developement bottleneck. 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...? :-) 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. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? In other words, your answer is: This just a not-yet-implemented feature? = You might also want to consider using -Lpath -llibrary, = instead of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. What's the difference if all I have are the static libraries anyway? I actually tried this, and had the exactly same list of allegedly undefined symbols... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote: Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? In other words, your answer is: This just a not-yet-implemented feature? Actually, it's it would not be necessary, if your code were organized to best common practices principles. Or more roughly It's not a feature. = You might also want to consider using -Lpath -llibrary, = instead of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. What's the difference if all I have are the static libraries anyway? I actually tried this, and had the exactly same list of allegedly undefined symbols... You can add -lxxx again, and it will only pull in those things that are missing. ... For my information: Why didn't you take John De Bowsky's advice to: ld $objlist `lorder $liblist | tsort -q` ??? I pointed you at tsort myself, but didn't provide the full command line like John did because I wanted the pain to be high enough that you would fix it the right way (reorganzing your library link order and using ranlib -- ppointed you at that, too) instead of glueing over the problem. Or are you on a holy crusade to get tsort incorporated into ld, so that most of the time, it will take a lot longer to link, with exatly the same results, since all the code everywhere else on the system has already solved the link order problem the right way? I have to say that, given a choice between make world taking several minutes longer and you not having to reorganize your code into logical component units, vs. it taking less time to do a make world, and one programmer having to *fix* their code, I have to pick you fixing your code. Also, this is a tools problem, and the tools provide a way (even if it's ugly) to get the behaviour you want, with a single option before your objects, and another one after. If you are going to convince anyone to make the change, it's going to have to be the tools people, and they are unlikely to be willing to take a hit on their benchmarks to please you, particularly if they've already externalized command line options so that you can solve your problem less automatically. By the tools people, I mean our linker vendor, the Free Software Foundation... not anyone in the FreeBSD Project. FreeBSD itself is *incredibly* unlikely to make a local hack to the GNU toolchain to support what you want being automatic, since David O'Brien, Peter Wemm, and others have sweat *blood* in order to get FreeBSD over to as much of the standard toolchain as humanly possible. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Friday 10 May 2002 12:51 pm, Terry Lambert wrote: = Mikhail Teterin wrote: =Is there a reason for it, or this just a not-yet-implemented =feature? It certainly seems like the latter -- why make the user =jump through all the sorting/reordering hoops? = = Generally, this won't be necessary for properly organized code. The = code in question is organized by software layering, right, so all you = have to do is link the libraries in order? = = In other words, your answer is: This just a not-yet-implemented feature? = Actually, it's it would not be necessary, if your code were = organized to best common practices principles. It is not my code. = Or more roughly It's not a feature. == You might also want to consider using -Lpath -llibrary, == instead of trying to link .a's directly. = =What would this do? = = Make it all go through the library linking code, instead of the = single object archive linking code. a .a file treated as an = object is not the same as a library. = = What's the difference if all I have are the static libraries anyway? = I actually tried this, and had the exactly same list of allegedly = undefined symbols... = You can add -lxxx again, and it will only pull in those things = that are missing. Thanks, this makes sense. = ... = = 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. = ??? I pointed you at tsort myself, but didn't provide the full command = line like John did because I wanted the pain to be high enough that = you would fix it the right way (reorganzing your library link order = and using ranlib -- ppointed you at that, too) instead of glueing over = the problem. It would probably be quite beneficial if you dropped this paternalistic attitude. Pain high enough... Please... = Or are you on a holy crusade to get tsort incorporated into ld, so = that most of the time, it will take a lot longer to link, with exatly = the same results, since all the code everywhere else on the system has = already solved the link order problem the right way? [The term holy crusade does not help either -- it is not even paternalistic, just plain non-sense...] Tsort is ALREADY incorporated into ld in some shape, because object files on command line or within one .a CAN be misordered. All I ask, is why the collections of object files provided by different static libs are/can not be treated as one big collection. = I have to say that, given a choice between make world taking several = minutes longer and you not having to reorganize your code into logical = component units, vs. it taking less time to do a make world, and one = programmer having to *fix* their code, I have to pick you fixing your = code. Of course. Does not seem like it will come to this, however. = Also, this is a tools problem, and the tools provide a way (even if = it's ugly) to get the behaviour you want, with a single option before = your objects, and another one after. Hmm, no. The only reliable option is to either build a library of all libraries or link the the object files into the executable directly. This, BTW, shows how inconsistent the current situation is -- the linker does not mind misordered object files, but is very picky about the order of static libraries (shared ones are can be misordered too, AFAIK). I don't see how one can sincerely defend its lack of what still appears to be a missing feature. = By the tools people, I mean our linker vendor, the Free Software = Foundation... not anyone in the FreeBSD Project. Ok. Thanks for the pointer. = FreeBSD itself is *incredibly* unlikely to make a local hack to the = GNU toolchain to support what you want being automatic, since David = O'Brien, Peter Wemm, and others have sweat *blood* in order to get = FreeBSD over to as much of the standard toolchain as humanly possible. Many thanks to them. -mi -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
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.
It would probably be quite beneficial if you dropped this paternalistic
attitude. Pain high enough... Please...
If I sounded paternalistic in my answer, it's because the question
being asked is really a newby question about how linkers work, and
really doesn't belong on the -current list.
Here is a more comprehensive answer, which does not leave the solution
as an exercise for the student:
Most linkers don't do what you want, which is make up for programmer
incompetence by doing an automatic topological sort on all symbol
dependencies, regardless of where or in what type of file the symbol
is defined, because most linkers treat archives and libraries very
differently than lists of object files.
This is the technically correct thing for them to do.
The topological sorting interior to archives (libraries) is
supposed to be accomplished via ranlib:
ranlib generates an index to the contents of an archive,
and stores it in the archive. The index lists each symbol
defined by a member of an archive that is a relocatable
object file.
You may use `nm -s' or `nm --print-armap' to list this in-
dex.
An archive with such an index speeds up linking to the li-
brary, and allows routines in the library to call each
***
other without regard to their placement in the archive.
**
This only works intra-archive, not inter-archive. For inter-archive,
you are expected to order the archives in the proper order, and the
breakup of objects into archives is assumed to have been arranged by
the original programmer such that they are a directed acyclic graph.
That is, it is expected that if you have three libraries, then they
define an order set of symbol dependencies, such that *no two of the
following are simultaneously true*:
a-b-c, a-c-b, b-c-a, b-a-c, c-a-b, c-b-a
Any place the original programmer has violated this assumption means
linking the library more than once, e.g. if both are true:
a-b-c, b-c-a
Then you need:
$(OBJS) -la -lb -lc -la
Such code is, by definition, broken. Relinking the a library because
the c library consumes symbols defined in a but not consumed by
$(OBJS) is *an incredibly ugly workaround* to the fact that the
object in the libraries are not order in DAG order, and then linked in
exterior edge-of-DAG order.
In fact, the link order above indicates that the dependency order is
cyclic rather than acyclic (a depends on b depends on c depends on a ...
infinity).
Tsort is ALREADY incorporated into ld in some shape, because object
files on command line or within one .a CAN be misordered.
Within one .a, they are only permitted to be misordered if ranlib
has been run on the archive (see the quotation of the ranlib manual
page, above).
Within multiple .a's, they are handled differently, because linking
against a .a file does not necessarily pull in all of the object
files in the archive. *This is intentional; it is by design*.
All I ask, is why the collections of object files provided by different
static libs are/can not be treated as one big collection.
This is a conflicting requirement.
You can't have it both ways.
It's my understanding that you are making libraries in the first
place in order to get around command line length limitations, and
have settled upon archives, rather than incremental linking using
ld -r -o A.o ${A_OBJS}.
If this is the case, it would probably be a good idea to choose
which objects go into which library carefully, to avoid ending
up with undefined symbols.
Alternately, if you insist on using .a files directly, as if they
were normal object files, someone has already posted that you should
probably use the --whole-archive argument, so that the archive
contents aren't pulled in *only* if they define symbols which are
in the current undefined symbol list, but to pull them in unconditionally
(i.e. treat them as a list of object files instead of an archive).
= I have to say that, given a choice between make world taking several
= minutes longer and you not having to reorganize your code into logical
= component units, vs. it taking less time to do a make world, and
Re: does the order of .a files matter?
On Friday 10 May 2002 04:35 pm, 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.
= It would probably be quite beneficial if you dropped this paternalistic
= attitude. Pain high enough... Please...
=
= If I sounded paternalistic in my answer, it's because the question
= being asked is really a newby question about how linkers work, and
= really doesn't belong on the -current list.
It looked (and still looks) to me like a bug or an incompleteness. That's
why I involved -current into it. The -stable is unlikely to make the changes
neccessary, but with -current I had hope.
= Here is a more comprehensive answer, which does not leave the solution
= as an exercise for the student:
=
= Most linkers don't do what you want, which is make up for programmer
= incompetence by doing an automatic topological sort on all symbol
= dependencies, regardless of where or in what type of file the symbol
= is defined, because most linkers treat archives and libraries very
= differently than lists of object files.
=
= This is the technically correct thing for them to do.
Doing what you explain by incompetence is no different from listing the
object files (.o) on the linker's command line in an arbitrary order --
say, alphabetically, as done by most of the FreeBSD's own Makefiles. Not
out of incompetence, but rather for neatness sake. The fact, that the
linker has no problems in this case shows the existing inconsitency.
= This only works intra-archive, not inter-archive. For inter-archive,
= you are expected to order the archives in the proper order, and the
This expectation is not even documented anywhere...
= Tsort is ALREADY incorporated into ld in some shape, because object
= files on command line or within one .a CAN be misordered.
= Within one .a, they are only permitted to be misordered if ranlib
= has been run on the archive (see the quotation of the ranlib manual
= page, above).
Your attempt to dodge explaining the other case -- that of misordered
object files _on command line_ has been logged.
= Within multiple .a's, they are handled differently, because linking
= against a .a file does not necessarily pull in all of the object files
= in the archive. *This is intentional; it is by design*.
Design of what? Of linker? If so, the design is inconsistent (broken?),
for it handles the same entities (object files) differently depending on
how they are given to it (in a single .a, on command line, in multiple
.a files).
= It's my understanding that you are making libraries in the first place
= in order to get around command line length limitations, and have
= settled upon archives, rather than incremental linking using ld -r -o
= A.o ${A_OBJS}.
Not quite. The software's original build is broken up into dozens of
interdependent libraries. They had no problems linking together on
neither Solaris, nor AIX, nor HP-UX, nor NT.
= If this is the case, it would probably be a good idea to choose
= which objects go into which library carefully, to avoid ending
= up with undefined symbols.
I'm not (yet) developing this software. I'm just trying to port it!
= Alternately, if you insist on using .a files directly, as if they
= were normal object files, someone has already posted that you should
= probably use the --whole-archive argument, so that the archive
= contents aren't pulled in *only* if they define symbols which are in
= the current undefined symbol list, but to pull them in unconditionally
= (i.e. treat them as a list of object files instead of an archive).
That suggestion I missed. But it looks like --whole-archive will suck in
everything, including the really unneeded objects.
Perhaps, the linkers on the commercial OSes I listed do use some smarter
equivalent of ``--whole-archive'' by default. IMO, it makes sense, since
those, who know, THEIR libraries are organized properly, and care for
the speed of linking can always add --no-whole-archive (or equivalent)
to THEIR makefiles -- speeding up their ``build world''.
= In the end, you will have to have already been told to solve it, in
= this thread, and which I have laid out, in no uncertain terms, in this
= email.
I think, the terms I used to say, that I already solved my problem,
were no less uncertain. My immediate problem that is.
I'm now readying my horse and armor for the trip to figure out, why is
this sort of gymnastics only needed with the OSF toolchain (actually, I
may be wrong here, since I did not _personally_ verify this thing links
on the other systems without the hoop-jumping).
= This, BTW, shows how inconsistent the current situation is -- the
=
RE: does the order of .a files matter?
Order-dependency on the link command line has been common behaviour
in linkers forever as far as I know. This includes the FSF GNU linker,
as well as the system linker shipped with Unix systems.
It is a useful feature, allowing one to insert other objects in
front, e.g. to override 'malloc' with a debugging version.
Some linkers have a -recurse or --recurse switch which causes them
to, once they'e reached the end of the pass, loop until there are
no undefineds or no symbols have been pulled in.
The approach I prefer over multiply listing archives is to
use -u to explicitly pull in the offending reverse dependency.
Quoting from the GNU ld 'info' page:
The linker will search an archive only once, at the location where
it is specified on the command line. If the archive defines a
symbol which was undefined in some object which appeared before
the archive on the command line, the linker will include the
appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not
cause the linker to search the archive again.
See the `-(' option for a way to force the linker to search
archives multiple times.
You may list the same archive multiple times on the command line.
This type of archive searching is standard for Unix linkers.
However, if you are using `ld' on AIX, note that it is different
from the behaviour of the AIX linker.
And:
`-( ARCHIVES -)'
`--start-group ARCHIVES --end-group'
The ARCHIVES should be a list of archive files. They may be
either explicit file names, or `-l' options.
The specified archives are searched repeatedly until no new
undefined references are created. Normally, an archive is
searched only once in the order that it is specified on the
command line. If a symbol in that archive is needed to resolve an
undefined symbol referred to by an object in an archive that
appears later on the command line, the linker would not be able to
resolve that reference. By grouping the archives, they all be
searched repeatedly until all possible references are resolved.
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.
Now, I suggest stopping the flame war, or take it somewhere else,
this really doesn't have anything to do with FreeBSD.
--don
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote:
= Most linkers don't do what you want, which is make up for programmer
= incompetence by doing an automatic topological sort on all symbol
= dependencies, regardless of where or in what type of file the symbol
= is defined, because most linkers treat archives and libraries very
= differently than lists of object files.
=
= This is the technically correct thing for them to do.
Doing what you explain by incompetence is no different from listing the
object files (.o) on the linker's command line in an arbitrary order --
say, alphabetically, as done by most of the FreeBSD's own Makefiles. Not
out of incompetence, but rather for neatness sake. The fact, that the
linker has no problems in this case shows the existing inconsitency.
You are wrong.
If you had listed the .o files seperately on the command line,
then the link would have succeeded, had you not exceeded the
command line length limit.
An archive is not a macro expansion for a list of the object
files it contains.
= This only works intra-archive, not inter-archive. For inter-archive,
= you are expected to order the archives in the proper order, and the
This expectation is not even documented anywhere...
Yes, it is. You need to read the ld and ar and ranlib man
pages, paying heavy attention to just what a static archive is
and isn't.
= Tsort is ALREADY incorporated into ld in some shape, because object
= files on command line or within one .a CAN be misordered.
I saw this. It's irrelevent because you said or within one .a.
It's not true for the within one .a, either (that's what ranlib
is for).
The command line linking is not handled by a topological sort.
It's handled by the fact that when you list objects on the command
line, you are forcing their incorporation into the resulting linker
output. When you specify archives on the command line, you are NOT;
you are saying pull the objects in this thing in, if you see that
they resolve unresolved externals *known to you at the time you
encounter the archive, in order, on the command line*.
Very different.
= Within one .a, they are only permitted to be misordered if ranlib
= has been run on the archive (see the quotation of the ranlib manual
= page, above).
Your attempt to dodge explaining the other case -- that of misordered
object files _on command line_ has been logged.
I'm not attempting to dodge anything. Your expectations of an
archive being treated as a list of the objects archived in it,
is wrong.
= Within multiple .a's, they are handled differently, because linking
= against a .a file does not necessarily pull in all of the object files
= in the archive. *This is intentional; it is by design*.
Design of what? Of linker?
Of the interaction of archive files and the linker.
If so, the design is inconsistent (broken?),
In your opinion.
for it handles the same entities (object files) differently depending on
how they are given to it (in a single .a, on command line, in multiple
.a files).
Your opinion disagrees with the documentation. At the command
line, type info ld; if you read the documentation, you will find:
The linker will search an archive only once, at the location where
it is specified on the command line. If the archive defines a
symbol which was undefined in some object which appeared before
the archive on the command line, the linker will include the
appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not
cause the linker to search the archive again.
See the `-(' option for a way to force the linker to search
archives multiple times.
You may list the same archive multiple times on the command line.
This type of archive searching is standard for Unix linkers.
However, if you are using `ld' on AIX, note that it is different
from the behaviour of the AIX linker.
= It's my understanding that you are making libraries in the first place
= in order to get around command line length limitations, and have
= settled upon archives, rather than incremental linking using ld -r -o
= A.o ${A_OBJS}.
Not quite. The software's original build is broken up into dozens of
interdependent libraries. They had no problems linking together on
neither Solaris, nor AIX, nor HP-UX, nor NT.
NT and AIX, I understand.
If you didn't have a problem on Solaris, I'd have to guess that
you used the C++ compiler, rather than the standard SunSoft ANSI
C compiler.
Solaris does a number of things that it shouldn't, and it leads
to programmers making bad assumptions about things like static
declaration of template class constructor instances.
On occasion, rather than generating link time errors, you end up
with run time errors, instead, which is really bad, if your testing
doesn't test each and every code path in your code.
= If this is the case, it would
Re: does the order of .a files matter?
Don Bowman wrote: Now, I suggest stopping the flame war, or take it somewhere else, this really doesn't have anything to do with FreeBSD. Yeah; it looks like he was really looking for an explanation of the failure of the OSF toolchain, and might not even be compiling on FreeBSD at all in the first place... 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Wednesday 08 May 2002 09:52 pm, Terry Lambert wrote: = Mikhail Teterin wrote: [...] = The most frustrating thing is, the number of such symbols varies = greatly with the order, in which I list the libraries on the command = line. Is not the linker supposed to make several runs over the given = libraries if needed? = = No. It doesn't make several runs. It only does that for single = object files. Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? = You might also want to consider using -Lpath -llibrary, instead = of trying to link .a's directly. What would this do? Thanks! -mi P.S. Yes, packing all object files into a single giant .a helped... -- Êàê, Âû ðàçâå áåç øïàãè ïðèøëè? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Mikhail Teterin wrote: = The most frustrating thing is, the number of such symbols varies = greatly with the order, in which I list the libraries on the command = line. Is not the linker supposed to make several runs over the given = libraries if needed? = = No. It doesn't make several runs. It only does that for single = object files. Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? = You might also want to consider using -Lpath -llibrary, instead = of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
