Thanks Alon. For scenario 1, is there any options of linker to be set so
that to force linker scan the .a throughly and float the potential multiple
definitions?
On Tuesday, November 24, 2015 at 11:35:16 AM UTC+8, Alon Zakai wrote:
>
> Yes, this is the standard behavior of .a linking, which
Not sure what you mean by "float"? In scenario 1, a and b are identical. If
one is linked in, the other can't be, without getting a duplicate symbol
error.
If by "scan the .a thoroughly" you mean to repeatedly go through the .a
while resolving missing symbols (so that the order doesn't matter,
For scenario 1, I use follow command:
U:\test>emcc -o test.js test.o --start-group libtest.a --end-group
but still no multiple symbol error, what I expect by "float" and "scan the
.a thoroughly" is that, say after linker scan the a.o in .a, there is
already no unresolved symbols, the default
Oh, you want to force the linker to include all the .o files inside the .a?
Try emcc -s LINKABLE=1. That tells emcc it might link that output code
again later, so it has to include all the parts of the .a. But, the option
also makes it not do the dead code elimination that we do automatically
Scenario 1:
//a.cpp
int add(int a, int b) { return 0; }
int add2(int a, int b) { return 0; }
int add3(int a, int b) { return 0; }
b.cpp is identical to a.cpp
//test.cpp
int add2(int, int);
int add3(int, int);
int main(){
add2(1,1);
add3(1,1);
return 0;
}
Compile and link without error:
Hey guys
I have a question about whether we can use embind to invoke polymorphic
functions on derived classes (when the derived class type definitions may
not be known). For example, say I have a class Foo which derives from a
pure virtual class IFoo. However, we don't publicly expose the
Yes, this is the standard behavior of .a linking, which emscripten follows.
It links in individual .o files from a .a when they are needed. In scenario
1, a is linked in, after which there are no undefined symbols, so b is not
linked in. But in scenario 2, add2 is still necessary, so b is linked
