Re: libraries and linking
If you want P not to depend on B you have to copy the code from B into A but why is the dependency chain an issue at all?
No VS doesn't copy anything from one library to another. Why do you think it does that?
Re: libraries and linking
Quote:
Originally Posted by
S_M_A
No VS doesn't copy anything from one library to another. Why do you think it does that?
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
These two points clearly demonstrate that project A is copying B's code and putting it into A.
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
These two points clearly demonstrate that project A is copying B's code and putting it into A.
In the end, the linker is going to need all the code necessary to build the final executable. You either pay for it now by making A bigger by including B , or pay for it later by specifying A and B when you build your application.
As to your question, either
1) make sure that modules in A do not call any modules in B, or
2) take the source code from B, add it to the project that builds A, and then you only have A to build.
Regards,
Paul McKenzie
Re: libraries and linking
Quote:
Originally Posted by
Paul McKenzie
In the end, the linker is going to need all the code necessary to build the final executable. You either pay for it now by making A bigger by including B , or pay for it later by specifying A and B when you build your application.
As to your question, either
1) make sure that modules in A do not call any modules in B, or
2) take the source code from B, add it to the project that builds A, and then you only have A to build.
Regards,
Paul McKenzie
indeed, Paul, but you're not answering my questions. (1) is not going to happen. (2) is not viable either.
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
indeed, Paul, but you're not answering my questions. (1) is not going to happen. (2) is not viable either.
I did answer your question. That is how you get rid of B.
Otherwise, what magic are you going to use on the linker when you call a function that resides in the B library?
Regards,
Paul McKenzie
Re: libraries and linking
Well you didn't mention that you actually linked A source with B library but yes in that case that's what will happen.
The "normal" way to do it is to create A and B as separate libraries and leave the linking to when P is built. "Normal" since everything depends on what you actually want to do...
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
I want to arrange things so that P depends only on A, and P does not depend on B. How do I arrange this?
Do you mean (a) actually getting rid of the dependency between P and B or are you just asking (b) how to prevent having to include B.lib in project P (or (c) add a dependency between projects P and B) in your solution? Note that in (b) or (c) P is still dependent on B.
Re: libraries and linking
Quote:
Originally Posted by
D_Drmmr
Do you mean (a) actually getting rid of the dependency between P and B or are you just asking (b) how to prevent having to include B.lib in project P (or (c) add a dependency between projects P and B) in your solution? Note that in (b) or (c) P is still dependent on B.
b is what I'm aiming for. I seem to have achieved this, but I'd like confirmation that I'm doing it the right way: how do I build A.lib so as it copies everything it needs from B?
Further, will I get linker errors if someone (not me) then builds P against A.lib and B.lib?
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
how do I build A.lib so as it copies everything it needs from B?
Don't know. Never understood the reason for that magic copies.
Quote:
Further, will I get linker errors if someone (not me) then builds P against A.lib and B.lib?
Yes. some functions will be in lib A and also in lib B and the linker won't be able to decide what to use.
Kurt
1 Attachment(s)
Re: libraries and linking
Please see the simplistic sample I made. It presumably imitates your case. Try to analyze two ways of building A and see the difference in A internals as well as resultant .exe dependencies on libs.
Re: libraries and linking
So, no comments, no questions? Seems I need to add some more to my last reply.
Quote:
i) if I tell project A where B's library files are, it produces an A.lib file which is bigger
This means that librarian extracts all required objects from B and archives them to A.
Quote:
ii) if I build app P against A, it will only do so successfully if project A knows about B's library files.
Of course it will. Remember, A depends on B, and when building P all the external dependencies, direct or indirect, need to be resolved.
There are two situations possible with P, A and B successful build:
Prerequisite: Library A functions require some functions from library B.
1. A is built extracting required functions from library B. Executable P depends only on functions from library A (as the one already includes all necessary functions from B). Once A is built this way, P never needs B to be included to the project. Please note, in this case A needs B to be included in A project.
2. Library A is build without including B in A project, so it contains references to B functions unresolved. In this case when linking P, functions from A still need the functions from B to be resolved, and this results in extra dependency on B for P. Please note, in this case P needs B to be included in P project.
In first case rebuilding A will need path to B to be known in A project. Rebuilding P will depend only on path to A.
In second case rebuilding P will need both A and B path to be known in P project.
In both cases some indirect or direct dependency on B exists. Just because A functions depend on B functions. The only way to eliminate dependency on B is moving B source code to A. This is what Paul already mentioned before.
Quote:
These two points clearly demonstrate that project A is copying B's code and putting it into A.
Well, rephrasing you, object code from B appears archived to library A. Yes, that's right.
Quote:
I want to arrange things so that P depends only on A, and P does not depend on B. How do I arrange this?
You already did. P depends only on A. If you never rebuild A, P is going to build with no problem ever.
Re: libraries and linking
Quote:
Originally Posted by
Igor Vartanov
So, no comments, no questions? Seems I need to add some more to my last reply.
This means that librarian extracts all required objects from B and archives them to A.
Of course it will. Remember, A depends on B, and when building P all the external dependencies, direct or indirect, need to be resolved.
you miss the point of my statement "if I build app P against A, it will only do so successfully if project A knows about B's library files." To make it clearer for you, perhaps I should state it thus: "I build app P against A and only A. P builds successfully if A knows about B. It does not build if A does not know about B."
Further, no-one has commented yet on the purpose of the "link library dependencies" option.
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
you miss the point of my statement "if I build app P against A, it will only do so successfully if project A knows about B's library files." To make it clearer for you, perhaps I should state it thus: "I build app P against A and only A. P builds successfully if A knows about B. It does not build if A does not know about B."
No I do not miss anything. In case your library A does not archive required objects from B, it is naturally for P build to fail. Please re-read my comments carefully.
Re: libraries and linking
Quote:
Originally Posted by
Igor Vartanov
No I do not miss anything. In case your library A does not archive required objects from B, it is naturally for P build to fail. Please re-read my comments carefully.
... you missed the bit that said
Further, no-one has commented yet on the purpose of the "link library dependencies" option.
Re: libraries and linking
I have cleverly discovered what "link library dependencies" is all about. I think it means "link against project dependencies". Are Microsoft good at misleading people?
Re: libraries and linking
The settings dialog says: Specifies whether or not library outputs from project dependencies are automatically linked in. Could they be more clear than that?
Re: libraries and linking
Quote:
Originally Posted by
c94wjpn
... you missed the bit that said
Okay, let's try this other way.
Code:
// library B
void b() { . . . }
// library A
void a()
{
b();
}
// application P
int main()
{
a();
return 0;
}
In case you build A providing no path to B, the library builds fine leaving symbol b unresolved. Further you build P "against A and only A". Now, how can you expect P to build successfully when the code chain depends on symbol b which still remains unresolved?
To resolve b, you either let P know about B, or otherwise A must know about B. In the latter case A copies object b to be inside A, and ultimately P copies object b from A. In the former case P should take that copy directly from B. (Actually, this is what my sample was all about :))
Does this description match to your case? If it doesn't, you need to explain the missed details.
