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, which otherwise it does!) then the --start-group and --end-group options help there. http://stackoverflow.com/questions/5651869/gcc-what-are-the-start-group-and-end-group-command-line-options Overall, though, .a linking is tricky. Order matters both inside the .a and outside. It's simpler in my opinion to never use .a files, and just link .o files into bigger .o files, it's all just bitcode anyhow. Using simple bitcode code files (.o/.bc) gives a simple predictable linking model, in which everything emcc is told to link, is just linked. On Mon, Nov 23, 2015 at 9:22 PM, Jian Huang <[email protected]> wrote: > 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 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 in. But b contains add, which is a duplicate symbol because of a, >> and you get that error. >> >> On Mon, Nov 23, 2015 at 7:09 PM, Jian Huang <[email protected]> wrote: >> >>> 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: >>> U:\test>emcc -c a.cpp >>> U:\test>emcc -c b.cpp >>> U:\test>emcc -c test.cpp >>> U:\test>emar rc libtest.a a.o b.o >>> U:\test>emcc -o test.js test.o libtest.a >>> >>> Scenario 2: >>> //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 >>> int add(int a, int b) { return 0; } >>> int add2(int a, int b) { return 0; } >>> //int add3(int a, int b) { return 0; } >>> >>> Compile and link with error: >>> U:\test>emcc -c a.cpp >>> U:\test>emcc -c b.cpp >>> U:\test>emar rc libtest.a a.o b.o >>> U:\test>emcc -o test.js test.o libtest.a >>> ERROR: Linking globals named '_Z3addii': symbol multiply defined! >>> >>> My question is why scen2 throw errors but not happen in scen1? Is this >>> the standard behavior of emscripten build-chain? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
