|
This is going to get really confusing. Sorry in advanced.
I understand what static and dynamic Linking are, and how they works, but one point that confuses me is:
Does linking work in just one direction, or does it always work in both.
Let me clarify. If I write some code that uses the C Standard Library, we would of course say that I am linking to it. However, would you also say that the C Standard Library links to my code, even if it doesn't use anything I wrote?
One way
--------
Code X uses Code Y, therefore Code X links to Code Y.
Code Y does not use Code X, therefore Code Y does not link to Code X.
Two way
---------
Code X uses Code Y, therefore Code X links to Code Y.
Code Y does not use Code X, but Code X uses to Code Y, therefore Code Y links to Code X.
If Linking is Two Way, then is there a proper term for when one work uses another work. I think it would be something like "subroutine call", but I'm not sure how much that covers.
Again, sorry for any confusion. Thanks for your help.
Jacob W.
|
|
|
|
|
When you compile you create object files.
When you link you create an executable from those files.
If file A uses something in File B then the linker resolves the reference from A to B
If file B uses something in File A then the linker resolves the reference from B to A
So it is one way from that respect.
Object B will not know anything about what objects are linked to it (it can't - how would a generic library know anything about your code?)
Circular references (i.e. from A to B and also from B to A) are (generally speaking) not allowed.
|
|
|
|
|
Okay, I understand about circular references. That makes sense.
One thing I forgot to clarify is that I'm trying to understand this in terms of Licensing. What is the proper term when one Licensed Work uses another. I should have mentioned that first. That does change a few things. Sorry.
So technically, it seems Linking is one way. There does seem to be some ambiguity there though. I guess a better question would be what do the Licenses consider linking.
|
|
|
|
|
Licenses don't really consider linking. They set bounds on acceptable use, so a license may say that if you make use of the library, the acceptable use is that you must make the source freely available under the same license (for instance).
|
|
|
|
|
GPL does in fact consider linking. Link to a GPL library and you must release your code under GPL. There is a specific exemption for the gnu standard libraries, which are in fact released under a different license called LGPL that gives you a free pass for linking.
If your code creates an unresolved reference to a symbol in another library, then your code links to that library.
A library can create an unresolved reference to a symbol in your code. Then it links to your code. The symbol "main" is a frequently occuring example.
|
|
|
|
|
Sorry to be the bearer of bad tidings, but as I said, licenses don't consider linking as there is no legal basis for linkage - that's a computing definition, not a legal definition. What you are talking about is covered in legal terms by "derivative work".
|
|
|
|
|
Yeah, I see that the terms of the GPL have been updated to use that language. My knowledge has apparently fossilized.
|
|
|
|
|
I wouldn't have known what it meant if I hadn't had to sit with the legal sharks and work out licenses for our software. It's as pleasant as pulling your lips off by tearing your toes off.
|
|
|
|
|
I guess that, if you have some object (without source) that you want to link your code to, and you want to distribute your cide, you would have to look at the individual license concerned .
It's unlikely a license would talk specifically about linkking - more likely about use and re distribution.
For example, if you wrote some code that used a word processor's spell checker, it is likely the license for the word processor would stipulate that you could not distribute the dell concerned - so any user would have to buy the wp package ass well as your product.
If you think about it, it makes simple logical sense - otherwise you could just write a wrapper around MS Office and sell it as your own product!
|
|
|
|
|
It seems your capacity-responsibility balance needs to be adjusted a bit.
Take care of cases 16531 to 16630. Like, NOW.
Linking, technically, is two way.
You'd still say you are linking to the standard library, because in that case it's primarily one way - even if you do pass the one or another callback to it.
There is usually a primary direction, either in architecture, or amount of functionality. Use that.
|
|
|
|
|
A link in this sense is one way. A library will expose various places that you can link to it (a public API or 'hooks' depending on which lexicon you're using), but it exists as a self-contained entity and doesn't need knowledge of what might be using it. When you use a library in another project, you are linking to it, but the library doesn't know about that connection.
There are cases when linking is a two-way thing, usually to do with communication: a client-server application has a link between the client and the server, and both sides need to know about the contract of communication (i.e. the protocol). Modification to either end can often require an adjustment to the protocol and the other end, which makes the link two directional.
|
|
|
|
|
You can think of your software as a component, like the engine of a car. You sell the engine, not the car. And if your engine itself requires third party components, say spark plugs, you purchase the spark plugs. Or you ask your customer to purchase the spark plugs for you.
You might very well imagine a reverse situation where you are an engine manufacturer and want a partner to embed your engines into a car for you. So you would purchase the parts, car body, accessories... and assembly to this partner, and become a car seller under your brand.
In any case, the licensing right goes to whom owns the technology and makes the corresponding part of the work.
Hope it helps.
|
|
|
|
|
The linker only does "one-way" linking. You tell it to start with the undefined symbols in the code you wrote, and resolve them using the defined symbols in some library, not the other way around.
The confusion stems from the English language, where the word "link" does not imply directionality.
There might be additional confusion because the symbol resolution can be bidirectional -- it is possible for the library to reference a symbol it doesn't contain, and you must supply it in the code you write or the program won't successfully link, and therefore won't be able to run. The most common example of this is main().
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
