Talk:Dynamic linker

Rewrite

I have found that the article is missing large sections of information and contained a decent amount of disinformation. I have rewritten the article, if you believe the previous article is more accurate please merge that article with this one to produce a mixed article since the previous one had many errors in it and was light on details. While don't believe this new article is perfect I do believe it is an improvement. CupOfJava (talk) 11:51, 3 December 2009 (UTC)

Linux doesn't use .interp?

The article says

The GNU/Linux based operating systems implement a dynamic linker model where a portion of the executable includes a very simple linker stub which causes the operating system to load an external library into memory. This linker stub is added at compile time for the target executable. The linker stub's purpose is to load the real dynamic linker machine code into memory and start the dynamic linker process by executing that newly loaded dynamic linker machine code. While the design of the operating system is to have the executable load the dynamic linker before the target executable's main function is started it however is implemented differently. The operating system knows the location of the dynamic linker and in turn loads that in memory during the process creation. Once the executable is loaded into memory the dynamic linker is already there and linker stub simply executes that code. The reason for this change is due to the fact that ELF binary format was designed for multiple Unix-like operating systems and not just the GNU/Linux operating system.

That sounds more like a description of the SunOS 4.x operating system's dynamic linker model, where the C startup code mapped ld.so into memory and ran it, rather than the dynamic linker model used in, for example, SunOS 5.x, where the .interp section of the ELF executable has the pathname of an "interpreter" for the executable, and, for dynamically-linked executables, that "interpreter" is the run-time linker. (That was done so that the executable image would not have to contain any system call traps - not even the ones that the SunOS 4.x C startup code used to open the run-time linker and map it into the address space - and therefore would not, in any way, depend on the binary interfaces for any system call traps being stable.) Does Linux really do that differently? Does "The reason for this change is due to the fact that ELF binary format was designed for multiple Unix-like operating systems and not just the GNU/Linux operating system." mean that this was done to support running non-Linux ELF binaries on Linux systems? Guy Harris (talk) 23:51, 20 June 2010 (UTC)

This section is outdated and the article no longer contains the above citation, so this section can even be removed.
man ld.so on a current linux (Ubuntu 14 LTS in my case) says:

The dynamic linker can be run ... indirectly by running some dynamically linked program or library. In the ELF case, the dynamic linker which is stored in the .interp section of the program is executed.

So linux does use .interp, at least for today. -- Juergen 5.146.93.86 (talk) 01:41, 13 February 2016 (UTC)

And that claim about the stub was removed back in 2015 anyway. Guy Harris (talk) 02:37, 13 February 2016 (UTC)

Source of Mac OS X

"While the source code to Apple's Mac OS X dynamic linker is not available, an similar open source version is. The open source version of the Apple Mac OS X platform is often simply called Darwin. While at one time the source code for both were the same, with small sections of the code omitted by Apple, the source code today has diverged and the two are actually very different, with patches and changes kept in sync between the two different source code trees (SourceCaches).[citation needed] The open source version of dynamic linker (dyld) can be found at Apple's open source web site [9]"

I think it is not clean, where is any links to the differences between code in the Mac OS X and in the Darwin? One is just open source of the part of the Mac OS X. —Preceding unsigned comment added by 80.250.64.35 (talk) 08:53, 21 September 2010 (UTC)

The claim that Mac OS X uses code different from the Darwin code is false. Guy Harris (talk) 10:01, 12 March 2012 (UTC)

Linker execution

I think the explanation of linker execution used throughout this page is somewhat inaccurate, particularly the tidbit saying that a new process is created for the linker. I know in Linux, at least, that this is not true. While the linker (ld.so) is, indeed, another executable, I'm certain that the kernel doesn't create a new process for it. Instead, it maps the the linker into the new process's address space and jumps to it. Aikigaeshi (talk) 23:03, 11 March 2012 (UTC)

I don't think they intended to say that a process is created for the dynamic linker separate from the process that's running the dynamically-linked executable image. If you're referring to "In most Unix-like systems that use ELF for executable images and dynamic libraries, most of the machine code that makes up the dynamic linker is actually an external executable that the operating system kernel loads and executes first in a newly constructed process address space.", I think "newly constructed" refers to the address space, not the process - if an already-existing process does an exec call that starts a dynamically-linked executable, the exec call clears out the old address space and constructs a new address space, and then loads the run-time linker, not the executable image, into the address space and transfers control to it. It passes to the run-time linker a file descriptor that refers to the executable image; the run-time linker then maps the executable image into the address space and does the linking, mapping shared libraries into the address space as well. When it's done, it transfers control to the executable image's start code. (With a call such as posix_spawn(), a new process is, of course, created and launched with the run-time linker, but that process ends up running the executable image, so, again, the run-time linker and executable image run in the same process.)

(This was done in order to avoid the executable image's startup code having to make any system calls to load the run-time loader into the address space; the SunOS 4.x shared library mechanism, from which the SVR4 mechanism was derived, started the run-time linker that way, but that meant that, to preserve binary compatibility, the system call trap interface for those system calls couldn't be changed in a binary-incompatible fashion. In a system where the run-time linker is what's loaded by the exec call, the system ABI can be defined entirely in terms of procedure calls to routines in dynamically-linked libraries, with no need to expose the system call trap interface as part of the ABI; that was one of the goals of the SVR4 shared library mechanism, as I remember from when I was at Sun during the early days of the SVR4 work.) Guy Harris (talk) 00:56, 12 March 2012 (UTC)

I've rewritten the clauses to which I think you're referring, in the hope of making them clearer. Guy Harris (talk) 10:06, 12 March 2012 (UTC)

Proposed merge with Dynamic loading

The two subjects are so closely related, and so confusable (I'm still a bit confused as to the exact distinction), that I really don't think we can hope to get the distinction right if we keep trying to cover them in separate articles. —SamB (talk) 00:42, 21 July 2015 (UTC)

There are two types of "code loading at run time".

A program can be linked with a dynamic library, which means that no code from that library will be incorporated into the program's executable image; instead, the executable image will say "I need library XXX" and will list routines it uses from that library. The library will be loaded at run time, either when the program starts or when a reference to a routine from the library is made. References to routines in the library are done, in the source code and the object code to which it compiles, in the same fashion that they would be done if, at link time, the program were linked with a static version of that library; you would make ordinary procedure calls.

A program can also make explicit procedure calls to load a dynamic library/plugin, and to look up routines, by name, in that library/plugin. Calls to those routines would be done through pointers, or other handles, returned by a "look up routine by name" call.

Dynamic loading deals with the latter type of code loading at run time. Dynamic linker deals with the former type, although the dynamic linker is usually responsible for both forms of code loading.

I'm not sure what the right way to structure that would be. Guy Harris (talk) 02:21, 21 July 2015 (UTC)

Hello! IMHO, we should keep these two topics in separate articles. In a few words, dynamic loading is a result of what a dynamic linker does, but dynamic loading can also be completely separate from it, as Guy Harris already explained. — Dsimic (talk | contribs) 10:04, 18 August 2015 (UTC)

It looks to me like it will take a very long time (10 years or more) until people find it really, really obsolete that there are quite a couple of very closely related articles on linking and loading and all that. Until then the self-declared practising owners of the articles will reject merging the topics and also structural changes or just "too big" changes on "their" articles. They focus on their "property" and they seem to have enough time and "WP power" to enforce their "rights". It does make sense to have at least a proper compact list of all the related articles, and this list belongs into the respective "See Also" sections, and they should not just be spread and scattered across the text. But of course as diverse as WP is in general there are also as controversial positions on whether references already to be found somewhere within the text should also get listed maybe a second time within the "See Also" section. I am not sure whether anybody interested in the entire topic on linking and loading will come across our discussion here on this discussion page recognizing that some merging must be done but that it gets recected by more powerful editors, but this at least is a location where the self-declared principals of WP need to behave like ordinary people and "allow" discussions without reverting them, if they don't like them. --johayek (talk) 17:38, 23 August 2015 (UTC)

The edit was meant to be called "merging linking and loading into something comprising these topics and maybe more", but I accidentally came across the Enter key too early.--johayek (talk) 17:41, 23 August 2015 (UTC)

Please see WP:SEEALSO, there's no point in having a mile-long "See also" section. As I've already suggested, we should instead think about creating a navbox that would bring all relevant articles together, and have it added to multiple articles. The benefits of such an approach would be significant and not limited to a single article, if you agree. — Dsimic (talk | contribs) 17:52, 23 August 2015 (UTC)

Dynamic linker and dynamic loading are different topics and therefore should be discussed in separate articles. It would only confuse people, if linkers and loaders would be lumped together in a single article as if they were the same. --Matthiaspaul (talk) 17:54, 22 May 2016 (UTC)

I like to think loading deals specifically with a process's own address space and linking is to anything else. Therefore it's not the same thing and should not be combined. Nerdykitten (talk) 08:42, 4 December 2016 (UTC)