Comments on: Linkers part 11 http://www.airs.com/blog/archives/48 Ian Lance Taylor Wed, 7 Jan 2009 03:00:12 +0000 http://wordpress.org/?v=1.5.2 Comment on Linkers part 11 by: Ian Lance Taylor http://www.airs.com/blog/archives/48#comment-12958 Thu, 01 May 2008 01:19:11 +0000 http://www.airs.com/blog/archives/48#comment-12958 Yes: when an object comes in from an archive, any undefined references that it makes must be satisfied. For example, they may be satisfied by pulling in other objects from the same archive. Yes: when an object comes in from an archive, any undefined references that it makes must be satisfied. For example, they may be satisfied by pulling in other objects from the same archive.

]]> Comment on Linkers part 11 by: haizaar http://www.airs.com/blog/archives/48#comment-12937 Wed, 30 Apr 2008 10:49:35 +0000 http://www.airs.com/blog/archives/48#comment-12937 "Once the linker decides to pull an object in from an archive, that object is treated as though the user named it on the command line. " Which means that all unresolved symbols from that object (whose probably are even unrelated the my program) will be resolved as well? “Once the linker decides to pull an object in from an archive, that object is treated as though the user named it on the command line. ” Which means that all unresolved symbols from that object (whose probably are even unrelated the my program) will be resolved as well?

]]> Comment on Linkers part 11 by: avjo http://www.airs.com/blog/archives/48#comment-9333 Sat, 12 Jan 2008 05:11:52 +0000 http://www.airs.com/blog/archives/48#comment-9333 Thanks Ian ! Thanks Ian !

]]> Comment on Linkers part 11 by: Ian Lance Taylor http://www.airs.com/blog/archives/48#comment-9329 Sat, 12 Jan 2008 02:21:07 +0000 http://www.airs.com/blog/archives/48#comment-9329 Yes, when the new object file is pulled into the link, all its symbols are checked. The new definition of B will take precedence over the previous weak definition of B. Once the linker decides to pull an object in from an archive, that object is treated as though the user named it on the command line. Yes, when the new object file is pulled into the link, all its symbols are checked. The new definition of B will take precedence over the previous weak definition of B.

Once the linker decides to pull an object in from an archive, that object is treated as though the user named it on the command line.

]]> Comment on Linkers part 11 by: avjo http://www.airs.com/blog/archives/48#comment-9323 Fri, 11 Jan 2008 15:58:37 +0000 http://www.airs.com/blog/archives/48#comment-9323 Hi Ian, I have a question about the process of linking archives. Let's say the linker had an undefined symbol A, which it found in an archive, and therefore pulled out the whole object file in which the defined symbol A have resided. So now a whole new object joins the party. A is resolved, which is good. But what about other symbols that the new object file might have ? E.g. let's say there was another undefined symbol B which was already resolved to a weak symbol, but now, in the new object, there is a strong definition of B. Shouldn't the linker now take the new definition of B instead of the previously resolved now ? I guess it should, but for that, it need to check all symbols of the new object file that was just added. Does it do that ? Or maybe did I miss something here ? Thanks! ~avjo Hi Ian,

I have a question about the process of linking archives.
Let’s say the linker had an undefined symbol A,
which it found in an archive, and therefore pulled
out the whole object file in which the defined symbol A
have resided. So now a whole new object joins the party.
A is resolved, which is good.
But what about other symbols that the new object file
might have ? E.g. let’s say there was another undefined symbol
B which was already resolved to a weak symbol, but now,
in the new object, there is a strong definition of B. Shouldn’t
the linker now take the new definition of B instead of the
previously resolved now ? I guess it should, but for that,
it need to check all symbols of the new object file that
was just added. Does it do that ? Or maybe did I miss something
here ?
Thanks!
~avjo

]]> Comment on Linkers part 11 by: Ian Lance Taylor http://www.airs.com/blog/archives/48#comment-6454 Wed, 07 Nov 2007 14:23:43 +0000 http://www.airs.com/blog/archives/48#comment-6454 Unfortunately, I don't remember the exact details of the SunOS 4 a.out representation of stdin. I remember that until the GNU linker implemented the common symbol handling I described--adjust the size of the common symbol but do not include the archive member--it did not work correctly. It made sense at the time, but now I would have to look at an old SunOS system to recreate exactly what happens and why. I remember that it didn't have to work that way. It was just the way that libc.a happened to be implemented. Unfortunately, I don’t remember the exact details of the SunOS 4 a.out representation of stdin. I remember that until the GNU linker implemented the common symbol handling I described–adjust the size of the common symbol but do not include the archive member–it did not work correctly. It made sense at the time, but now I would have to look at an old SunOS system to recreate exactly what happens and why.

I remember that it didn’t have to work that way. It was just the way that libc.a happened to be implemented.

]]> Comment on Linkers part 11 by: avjo http://www.airs.com/blog/archives/48#comment-6434 Wed, 07 Nov 2007 08:30:32 +0000 http://www.airs.com/blog/archives/48#comment-6434 > The C library relied on this behaviour when implementing > the stdin variable. Interesting! Can you please elaborate ? Thanks ! > The C library relied on this behaviour when implementing
> the stdin variable.

Interesting! Can you please elaborate ? Thanks !

]]> Comment on Linkers part 11 by: Ian Lance Taylor http://www.airs.com/blog/archives/48#comment-5088 Wed, 10 Oct 2007 17:29:01 +0000 http://www.airs.com/blog/archives/48#comment-5088 Keep an eye on the binutils mailing list (see http://sourceware.org/binutils/). I'll announce gold there when it is ready to beta test. Keep an eye on the binutils mailing list (see http://sourceware.org/binutils/). I’ll announce gold there when it is ready to beta test.

]]> Comment on Linkers part 11 by: baruch http://www.airs.com/blog/archives/48#comment-5069 Wed, 10 Oct 2007 06:39:11 +0000 http://www.airs.com/blog/archives/48#comment-5069 Thanks for the information on how to get the objects and archives automatically sorted. I don't care much about the games that can be played, I just want the simplicity of letting the computer do the work I want it to do with the least amount of work on my part. FWIW, I'd be happy to beta test your gold linker, the application at my workplace takes several minutes to link, getting it down will be so nice. I'm willing to act as a guinea pig even for an incomplete linker ;-) Thanks for the information on how to get the objects and archives automatically sorted. I don’t care much about the games that can be played, I just want the simplicity of letting the computer do the work I want it to do with the least amount of work on my part.

FWIW, I’d be happy to beta test your gold linker, the application at my workplace takes several minutes to link, getting it down will be so nice. I’m willing to act as a guinea pig even for an incomplete linker ;-)

]]> Comment on Linkers part 11 by: Ian Lance Taylor http://www.airs.com/blog/archives/48#comment-5065 Wed, 10 Oct 2007 05:32:13 +0000 http://www.airs.com/blog/archives/48#comment-5065 Thanks for the note. I suspect that the original reason for the ordering was just simplicity. In the original Unix linkers, even the archives were searched in order; there was no archive symbol table. The tsort program, which can still be found on a Unix system near you, was used to sort the object files so that the ones which satisfied references of objects in the archive were found later in the archive. The lorder shell script built a partial order of dependencies, called tsort to build the total order, and built the archive in that order. Now that the ordering has been established, people take advantage of it to interpose libraries, so that you can supply your own definitions of functions overriding the ones in an archive. Come to think of it, I never got around to discussing interposition of shared libraries. I'll try to remember to do that some day. Thanks for the note.

I suspect that the original reason for the ordering was just simplicity. In the original Unix linkers, even the archives were searched in order; there was no archive symbol table. The tsort program, which can still be found on a Unix system near you, was used to sort the object files so that the ones which satisfied references of objects in the archive were found later in the archive. The lorder shell script built a partial order of dependencies, called tsort to build the total order, and built the archive in that order.

Now that the ordering has been established, people take advantage of it to interpose libraries, so that you can supply your own definitions of functions overriding the ones in an archive.

Come to think of it, I never got around to discussing interposition of shared libraries. I’ll try to remember to do that some day.

]]>