"-s LINKABLE=1" works. Thank you Alon! On Tuesday, November 24, 2015 at 2:10:34 PM UTC+8, Alon Zakai wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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.
