3

I know very well of the difference of static versus dynamic linking. What I want to know is, when linking statically (with a library like Winmm.lib on Windows), how does the linker "link" the pre-compiled format with the just compiled binary of the executable?

It does not have to pertain to any specific platform, OS, etc. I just want to know the process of which the linking takes place, and how that static "linking" binds an executable binary together that, when executed, forms a branch with the necessary system calls, routines, and low-level API access.

Basically, how does the compiled file get "put together" statically with the pre-compiled data, especially if they're coded differently?

I mean I know the library "exposes" routines, but where is the certainty that the called routines always work, and how can this be assured in a linking process?

EXAMPLE: I compile "Hello world.exe", and it is statically linked, and launched from the OS loader. Does something within the binary that the program itself linked with have all the necessary "instructions", "magic number", "checksum", etc. to perform the correct procedures, or the does the OS loader, on the fly, find what's needed to access, i.e. system calls, type of program header, other magic numbers, etc.?

I just want to thoroughly understand my linker's job, and how that linking makes the bonafide binary that the OS can handle, and get to my screen, as opposed to just plain instructions that the OS can't "branch" to any other process with.

  • just the same way it links normal object files together, cause that's all static libs are, a collection of object file packaged together – ratchet freak Dec 2 '13 at 20:30
1

A library is basically a collection of object files. An object file is basically a list of function names and signatures, together with the machine code instructions. When statically linking, when the linker sees a function call, it finds its name and signature in the object files, copies the machine code instructions to the exe, and changes the function call to point to the place it copied it to.

Dynamic loaders perform a similar task for dynamic libraries. They load the libraries into memory, look at the function calls the application is making, and change them to point to the library's executable instructions in memory.

  • dynamic library are linked by a list of jmp instructions so when calling a dynamic function you end up at the jmp which forwards to the actual code, the loader will fill in the jump list on load – ratchet freak Dec 2 '13 at 20:38
  • Can you explain how a specific library's specification can assure that compilation and linkage with it will give desired results for the OS, driver, etc.? For example, the memory map is the same on x86 regardless of OS, yet Ubuntu will use different libraries, executable formats, etc. to do almost the same finalized result as Windows(just differing formats for the most part). – user93262 Dec 5 '13 at 22:45
  • 1
    They use specific file formats to keep the symbol tables and such. See the ELF format for how it's done on Linux. – Karl Bielefeldt Dec 5 '13 at 23:00
-1

Well, first off, the called routines are not always guaranteed to work. I have quite the experience with making calls to libraries where something or other wasn't quite right and it all falls apart and burns in a glorious fire of seg faults. Ain't nothing there that's "assured" to work.

But if you use the library correctly, and the library is compatible with your environment, then it all works. That specific library's instructions match the expected usage of the surrounding environment. It knows that setting the bit at 0x0045BF will set a pixel on the screen, or whatever.

The linker's roll in all that is not to correctly tell the library how to use the surrounding environment, but to tell the original code how to use the library. A sound driver for 32-bit windows knows how to set the volume up and down. It just doesn't work in 64-bit Linux. You build a program statically linking that driver. The program wants to set the volume up, so it calls its (statically linked) sound driver* to do so. At compile time, the linker connects the volumeUp() function call to the appropriate address in the library which is the actual volumeUp() function. And the library simply knows how to handle sound in 32-bit windows.

*driver, library, same thing. Typically drivers are dynamically linked, but whatever.

  • Drivers are executables, yes. They are virtually the same as any other executable, with the difference that they access kernel memory. – user93262 Dec 5 '13 at 22:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy