Click here to Skip to main content
15,868,141 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
I've spent all morning googling how linkers work, but can't seem to find a clear answer to the following specific question:

Does the linker take the precompiled code in the library and actually stick a copy into your .exe, meaning the end user does not need the library on their system?

Or does the linker just stick a link to the library into your .exe, and you'll have to make sure the end user also has the relevant libraries installed on their system?

The reason I ask is I am working on code that uses the libraries for DirectSound Version 8.0. The latest DirectX SDK (June 2010) no longer has all the libraries for this older version of DirectSound. If I go back to an earlier version of the DirectX SDK which has the relevant DirectSound Version 8 libraries, will my final resulting .exe still work on an end user's system using the latest (2010) DirectX end user runtime?

Best regards

Paul
Posted
Updated 15-Apr-11 16:15pm
v2

will my final resulting .exe still work on an end user's system using the latest (2010) DirectX end user runtime?

Yes.

When you link with a .lib file it is actually put into your .exe or .dll file

Functionality from previous versions of DirectX are always available in the runtime for backwards compatibility with older applications (even though support has been officially dropped from the SDK)
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 15-Apr-11 22:57pm    
It is not "put". Name resolution and address translation is performed by a linker.
Please see my Answer.
--SA
mbue 16-Apr-11 8:35am    
This answer explains nothing about how libraries work. There is no piece of code 'putten' into the exe. Most system libraries contains only call forwards on system dll functions. The compatibility is only supported by the functions themselves.
Regards.
Anthony Mushrow 16-Apr-11 10:42am    
No, but it did answer the question directly. You don't need to have the .lib file on the target machine and older versions of DirectX will work on a machine with the latest runtime installed.
mbue 16-Apr-11 10:59am    
Thats the point - remember the headline is: "Trying to understand what a linker does with code in .lib files". The linked lib is only forwarding the linked calls. Is the needed directx version not installed the exe will fail.
Regards.
Anthony Mushrow 16-Apr-11 11:40am    
Which I also answered, the code in the lib file is linked into your application, even if the lib file is only a thin wrapper for calling the DirectX runtime DLL's so you don't need it any more.
You can find how a linker works in any decent book on system programming.
Here is a nice simple introduction, but you won't see much detail: http://en.wikipedia.org/wiki/Linker_(computing)[^].

Main idea of behind a traditional linker is separate compilation. A separate units of code are compiled separately into object files ()[^]. A lib file can be considered simple as a collection of the object files.

We're coming to the essence of the problem of separate compilation. The problem is: when a set of object files are bound together in a single executable file, the machine codes are put is a single address space. The tricky part is: when an object file is created, there is no information about of the addresses relative to other units (separate is separate: there is no information of other units). There is no information of the entry points of functions in other modules, they are presented in the form of symbolic names. The task of the linker is to resolve all relationships between symbolic names of different modules, arrange them in a single address space and translate all the addresses by some shifts calculated bases on individual positions of each unit in united address space of the resulting executable file.

In should be noted, that in most (almost all) platforms is is done separately for data and code address spaces and virtual memory is can be used, which is however transparent for the linker. There are several different memory models in different platforms. Dominating model in modern system is so called flat memory model, see http://en.wikipedia.org/wiki/Flat_memory_model[^].

—SA
 
Share this answer
 
Although SA answer is technically perfect, the OP question contains a subtle aspect that may be things not to go as expected by such an answer.

"Does the linker take the precompiled code in the library and actually stick a copy into your .exe, meaning the end user does not need the library on their system?"

The two part of th question can be unrelated, because ... it depends on what the linker actually links.
The linker resolve all static relations between compiled obj files, either individual or taken by a "collection of them called library". Surely, the "executor" machine doesn't need to have all what goes into the final exe (obj-s and lib-s).
But may be some of them, in some of its either exposed or simply internal methods, need some other "dynamic library" it will attempt to load runtime.

Your lib can be a "stub" acting as a proxy between your exe and a dll.

a) You need the cpp and h files to compile them into obj-s
b) You need a librian to merge the obj-s into static lib-s
c) You need a linker to merge obj-s and lib-s into ...
c1) ... a dll, and generate a stub lib to be furtherly linked to ...
c2) ... an exe, made up by obs-s and lib-s
d) You need an exe consistent operating system to run the exe and ...
e) The exe need to find through the OS all the dll it needs to call.

You don't need the "lib" to run the "exe", but you need the "dll" it eventually refers to.
 
Share this answer
 
Actually, there is another answer to this.

If the .lib is a static lib, then those functions in the lib that are called by your program are actually copied into your exe - at each point it is called. In this case, you do not need to supply the .lib file. Since it's a static library, there is no dll either.

However, if the .lib file is not a static lib (e.g. it's a link library that was generated by creating a dll) then the linkage to the dll is placed in your code wherever it is called. Your users will not need the .lib file, but they will require the .dll file that is associated with it.

I'm sure in the case you're asking about (DirectX), the .lib is a link library associated with a .dll, so the user won't need the .lib, but they will have to have the .dll.

Hope that helps.
 
Share this answer
 
I should only add to the post of krmed that this linking libraries are called:
- static link library - MSDN: When an application uses a function from a static-link library, the linker copies the code for that function into the application's executable file, and
- dynamic link library (DLL) - MSDN: The DLLs reside in their own executable files and are not copied into applications' executable files as with static linking.
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900