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 before compiling to JS, so this isn't a good option for production builds. Might be useful to get a warning on this type of problem though.
On Mon, Nov 23, 2015 at 10:03 PM, Jian Huang <[email protected]> wrote: > 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 behaviour is stopping scan, even > there's b.o in .a and a.o and b.o share the same symbols. How to make it > continue scanning so that we can find a.o and b.o share the same symbols? > Even the linker view this as a warning? > > On Tuesday, November 24, 2015 at 1:43:09 PM UTC+8, Alon Zakai wrote: >> >> 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. > -- 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.
